Field guide
The Workday Reality Check · Vol. 01
The Workday Position Management reality check.
A field guide for the people who run workforce planning on the system every fast-growing company quietly hates.
Begin reading
Field guide
A field guide for the people who run workforce planning on the system every fast-growing company quietly hates.
Contents
One argument across eight chapters, two appendices, and the diagnostic worksheet you can hand to your team on Monday.
Foreword
If you bought Workday Position Management hoping it would solve your headcount planning problem, this guide is for you. We are sorry. It was not going to.
This is not a guide that argues you made the wrong call. Workday is the right system of record. Position Management, on paper, is the right architecture. The problem is not what Workday is. The problem is what Workday was never designed to do.
Workday Position Management was designed for a world where positions are deliberate, durable, and rarely changed. The world where Workday was conceived shipped on quarterly release cadences, ran on enterprise sales cycles, and treated headcount as a slow object to be approved once a year and amended through change-control boards.
That world does not exist at your company. It probably has not for at least three years.
Your hiring managers live in Slack. Your TA team operates on rolling weekly priorities. Your CFO re-forecasts quarterly because the market re-forecasts you weekly. The position you approved in January is at a different level, in a different city, on a different team by April. None of that finds its way back into Workday.
This guide names what is happening, why it happens, what it costs, and what to do about it. We wrote it because we have sat in too many calls with too many people who all said some version of the same thing: I have followed every Workday best practice, and the data is still wrong, and I am still the person reconciling it on a Saturday.
We have receipts. We have customers. We have the integration cost figures from a competitor of ours that openly published them. We have the call transcripts. We have the internal language Workday admins use to describe their own system when they think no one is recording.
This is not a Workday hit piece. We will not pretend Workday is a bad product. Workday is an extraordinary system of record. The argument of this book is narrower and more useful: the system of record cannot also be the system of work. The gap between the two is now where every fast-growing company's hiring chaos lives. And there is something specific you can do about it.
Read with a pen.
— Tushar Makhija
CEO, TeamOhana
Executive summary
This guide makes one argument across eight chapters:
Workday Position Management is correct in theory and brittle in practice. The gap between the two is now where every fast-growing company's hiring chaos lives.
Five specific failures cause the gap:
Workday's create-requisition flow is too long, too clunky, and too tab-heavy for managers who run their lives in Slack. They Slack a request to HR. HR translates Slack into Workday. Half the fields are wrong.
Roles get re-leveled, dates slip, locations shift. None of it makes it back into Workday positions because the workflow to update them is the same workflow nobody completes.
Workday pushes the req to the ATS. Changes the recruiter makes do not flow back. Hire syncs fail. Tickets pile up.
Finance, HR, and TA each maintain their own spreadsheet. The three numbers never match. Reconciliation eats 60 to 80 hours a month across the three teams.
Slack threads and Google Sheets do not pass SOX. When the auditor asks for the documentation, your HRIS admin opens 47 tabs.
What works instead: a decision layer in front of Workday Position Management. Not a replacement. A front door. Requests originate, approvals route, changes track, and reconciliation happens automatically before the position is written to Workday. The system of record stays the system of record. The system of work happens somewhere built for it.
Six to eight weeks to implement. Two to four hours of HRIS admin time. API-based, not file-based. Bi-directional with Workday and your ATS.
The remainder of this book makes the argument in full, with the evidence behind it.
Chapter 01
It is 4:30 p.m. on a Wednesday in October 2009. A vice president of HR at a Fortune 500 manufacturer is on a conference call with her newly appointed CFO. The CFO has a question she has been asked sixteen times in the last two weeks and cannot answer: How many open positions do we have in the Phoenix plant?
Her HRIS team has spent four days trying to answer this. They have three different numbers. Finance has a fourth. The plant manager has emailed a fifth. Two of the five numbers are based on a spreadsheet a recruiter maintained in 2008 before she left the company.
This is the world Workday Position Management was designed for.
That world had three properties. First, positions were durable objects. A company would create a position once, fill it, lose the incumbent over years, refill it. The position outlived the people who held it. Second, position changes were rare, deliberate, and approved by name through a defined chain. Adding a new position was a budget event. Re-leveling one was a comp-committee decision. Third, the consumers of position data were HR and Finance, exclusively. Hiring managers did not consume position data. They consumed people.
In that world, Workday Position Management is correct architecture. It is, in fact, beautiful architecture. Every employee occupies a defined seat with a position ID, a compensation band, a level, a cost center, a reporting line. The position is durable. The employee is transient. The system of record records the seat, not the occupant. When the auditor arrives, the auditor can ask the system "which positions are filled, which are open, who approved them, and when," and the system can answer the question definitively. That is a property of real value. Public companies need it. The Sarbanes-Oxley Act requires some version of it. The Workday architecture is not the problem.
The problem is that almost none of the assumptions of that world hold anymore at the kind of company that reads this guide.
Three forces broke the assumptions, and they broke them in compounding order.
Force 1 · Velocity
The velocity of business itself. Companies that used to ship a major product release every nine months now ship every two weeks. The plans that drive headcount used to be annual. Now they are quarterly at slowest, weekly at fastest. The position you needed in January is not the position you need in April. The headcount approved in Q1 has been re-scoped three times before the rec is opened.
Force 2 · UX
The consumerization of software. The hiring manager who fills out your Workday requisition form has spent the last decade running her professional life inside Slack, Notion, Linear, Figma, and a dozen other tools that share a design vocabulary. Single-purpose flows. Inline previews. One-click actions. Real-time feedback. She opens Workday and she does not see software designed in 2009. She sees a tax return.
Force 3 · Centrality
The strategic centrality of headcount itself. In the world Workday was designed for, headcount was a back-office concern. Hiring rooms were quarterly. Reorgs were biannual. Today headcount is the strategic conversation. Every board meeting includes a headcount slide. Every earnings call invites questions about operating leverage. Every CFO conversation with the CEO eventually arrives at the question: what are we doing on people? That conversation is not happening in Workday. It is happening in Slack threads and Google Docs and the cars after the board meeting. The system of record does not know.
These three forces did not stop Workday from being a system of record. They turned Workday into the wrong place to do the actual work of headcount planning. The system kept doing what it was designed to do. The work moved elsewhere. The gap between them is now where every fast-growing company's hiring chaos lives.
To be precise about what we are arguing, it helps to be precise about what we are not arguing.
Capabilities to preserve
Workday Position Management is excellent at:
These are real capabilities. We are not asking you to throw them away. Anything we propose has to preserve every one of them, and the architecture we propose in Chapter 5 does exactly that.
What Workday Position Management is not good at is everything that happens before the position exists in the system. The conversation. The negotiation. The change orders. The level disputes. The location debates. The "actually we don't need that role anymore, can we use the budget for these two instead." The hundred small decisions per week that make up the actual work of headcount planning in a 1,500-person company.
That is the conversation we are going to have for the next seven chapters.
A note from the field
"I joined this company a year ago thinking I was going to do strategic HR. I spend half my week patching positions in Workday because someone changed a level in greenhouse and the sync broke. I am not a strategic HR leader. I am a human cron job."
— HRIS Lead, public B2B SaaS company, 2,200 employees
Chapter 02
It is 9:47 a.m. on a Monday in March. The head of TA Operations at a 1,200-person fintech opens Slack to a thread her CFO started at 7:14 a.m. Eastern. The CFO has been on a flight from Singapore. The thread has fourteen replies.
The question that started the thread: What is our true open headcount in engineering right now?
By 9:47, the thread has produced four numbers. The Workday position count is 47. The greenhouse open req count is 41. The FP&A forecast says 52. The engineering VP's spreadsheet, which his Chief of Staff maintains by hand, says 38. The CFO wants to know which one is right before he gets to his next meeting at 10:30.
The head of TA Operations knows the answer to the CFO's question. The answer is: all of them, depending on what you mean by open, and none of them, depending on what you mean by right now.
She does not type that. She types: Let me reconcile. Back to you in 30 minutes.
She has been at this company for sixteen months. She has reconciled this number, by hand, at least forty times. Each time it takes her an hour. Each time the answer is slightly different by the time she returns to the thread, because by then a backfill has been requested in Slack, a role has been pulled forward in Q2, and someone in product has hired through a referral she did not know about.
This scene is not unusual. This is the average Monday at the average mid-stage Workday customer.
The reason this happens is the central argument of this book. Two systems are required to run headcount, and one of them does not exist at most companies.
The system of record is the place where the truth is stored after a decision has been made. Workday is the canonical example. The system of record is auditable, slow, forms-driven, governed, and durable. It exists so that, when the auditor asks who approved what when, the answer is unambiguous. It exists so that, when you generate the year-end census, the census matches reality. It exists so that the position ID, once issued, is stable for the life of the position.
The system of work is the place where the decision is made. Slack threads. Google Sheets. Calendar invites with three department heads. The five minutes after the executive standup when the VP of Engineering and the VP of People exchange a quick "we should up-level that role." The hallway. The hotel bar at the offsite. The system of work is fast, messy, real-time, conversational, and almost entirely unaudited.
Records the decision after it's made. Position IDs, approval chains, the year-end census, the answer to the auditor.
Where the decision is actually made. Threads, the five minutes after standup, the hallway, the offsite bar, the chief-of-staff's tracker.
In the world Workday was designed for, these two systems were the same system, because the system of work was a quarterly forms-and-meetings world that mapped neatly to the system of record. The decision was slow. The recording was slow. The cadences matched.
They no longer match. The system of work has accelerated into Slack-speed. The system of record has stayed at Workday-speed. The gap between them is now where the work actually happens, and where none of it gets recorded properly.
You can pretend the gap is not there. Many companies do. They keep telling each other that Workday is the source of truth and treating it as if it were. When asked for headcount data, they pull a Workday report. When the data is wrong, they blame the people who failed to update Workday.
This works until it does not. The point at which it stops working is usually one of three moments.
The first is a SOX audit. The auditor asks for the documentation of the approval chain for a specific role re-leveling. The HRIS admin opens Workday. Workday shows the position at the new level. Workday does not show the conversation in Slack, the email from the CHRO, the budget reallocation in Adaptive, or the comp committee minutes. The auditor asks for the documentation. The HRIS admin spends two days assembling it from four different systems and a personal recollection. The audit passes, but the company has just paid for two days of HRIS labor and put a flag on the audit response that says "manual reconciliation required."
The second is a hiring miss. The CFO has been forecasting a hire on July 1. The recruiter has been working the role since March. The hiring manager re-scoped the role in May, in Slack, and the recruiter updated the rec in greenhouse but did not update the position in Workday. The candidate accepts the offer on June 28. The hire creation in Workday fails because the position level no longer matches. The HRIS team scrambles for three days. The candidate's start date slips. The CFO reports the miss. The market punishes.
The third is a re-org. Leadership decides on Friday to consolidate two functions. Someone in the room says "what does this do to our positions in Workday?" No one in the room knows. The HRIS team gets the request on Monday and spends two weeks mapping the re-org to position-level changes. The re-org is announced before the position changes are made. Two months later, the org chart in Workday still reflects the pre-reorg structure, and finance is generating reports against the old structure without realizing it.
These are not edge cases. They are the median company-year at a mid-stage Workday customer. They happen because the work of headcount planning has moved out of Workday, and Workday has not moved with it.
The metaphor we use with our customers, because it lands on the first try, is this: Workday is the courthouse. The street is everywhere the work actually happens.
The courthouse is where the marriage is recorded. The street is where the couple met, fought, made up, decided to get married, planned the wedding, fought about the planning, made up again, and finally showed up at the courthouse on a Tuesday afternoon. The courthouse does not know any of that. The courthouse only knows that two people signed a form on a Tuesday afternoon.
You cannot abolish the courthouse. The state requires the form. The auditor will ask for the form. The form is the durable record. We are not arguing for the abolition of the courthouse.
We are arguing that you cannot also conduct the relationship at the courthouse. The relationship happens on the street. If you tried to make every conversation, every fight, every reconciliation happen at the courthouse, you would either stop having relationships or stop being able to record them. In practice, every Workday customer is some version of both.
The argument of this book is that the street needs its own infrastructure. Something built for the speed and messiness of the actual work, that still feeds the courthouse when the work produces a recordable event. Not a replacement for the courthouse. A complement to it.
What that infrastructure looks like is the subject of Chapter 5. Before we get there, we need to look closely at what the gap is costing you, in five specific ways.
From the calls
"We're listing in the US this year. Clean data on one source of truth is no longer important. It's regulatory."
— Head of Recruitment Operations, dual-listed fintech preparing for US IPO
Chapter 03
Workday Position Management does not fail in one large, obvious way. If it did, you would have ripped it out by now. It fails in five specific small ways, each of which is survivable in isolation, and which compound when they appear together. In every customer of ours that switched on TeamOhana in front of Workday, all five were running simultaneously.
This chapter walks each one. The structure is the same for each: the promise, the lived reality, the root cause, and what it costs. The scenes are drawn from real customer calls, composited and anonymized where necessary.
12–18 fields. 4–7 tabs. The form your hiring manager will never finish.
47 of 612 positions wrong by February. By April, 30–50% drift.
Workday pushes. The ATS doesn't push back. Hire syncs fail.
Workday, the ATS, FP&A — three numbers, ninety-minute reconciliations.
A Slack thread, a thumbs-up emoji, a change in Workday. Not SOX.
Failure mode 01
It is 2:11 p.m. on a Thursday. Maya, the head of Product Engineering at a 1,500-person Series D infrastructure company, opens her laptop in the kitchen between back-to-back interviews. She has three open Slack threads, one of which is the one she has been meaning to handle for two days. Her VP of Engineering pinged her on Tuesday: we need to backfill Aaron's role, and I'd like to up-level it to a Staff. Can you get the rec going?
Maya does not open Workday. She opens Slack. She types: @Christine can you start a rec for Aaron's backfill, up-level to Staff, San Francisco or remote, I'll send you the JD by EOD. She hits send. She closes the laptop. She walks back into her interview.
Christine, who is the HRIS Lead for the company, sees the Slack message at 2:14 p.m. She opens Workday. She opens the Create Job Requisition flow. She fills in fourteen required fields. She does not have the JD, so she leaves that for now. She does not have the comp justification, so she leaves that. She does not have the hiring manager's official sign-off on the up-level, so she pings Maya in Slack: for the up-level to Staff, can you confirm in writing? I need to attach to the comp justification. Maya does not respond for forty-five minutes because she is still in interviews. Christine moves on to the next ticket in her queue.
By 5 p.m., the rec is not open. By 5 p.m. the next day, the rec is not open. The recruiter who was supposed to start sourcing on Monday is told on Monday morning that the rec is "in progress." Two weeks pass before a candidate is in pipeline. The official record in Workday eventually shows a clean process, properly approved, properly documented. The lived reality was a two-week delay introduced by friction nobody chose.
This is failure mode one.
Workday's Create Job Requisition flow is the official, governed, audit-ready way to add a position to the system. It collects the required fields, routes to approvers, links to position management, generates an audit trail, and produces a clean record. It is designed to be the single canonical workflow for requisition creation across the enterprise.
Hiring managers do not complete it. Across every Workday customer we have worked with, the vast majority of requisitions are not initiated by the hiring manager directly. They are initiated by an HR business partner, an HRIS admin, a TA coordinator, or a People Ops generalist who translates a Slack message or an email into the Workday form. The hiring manager touches Workday, if at all, to approve a flow that someone else already filled out on their behalf.
This is not a training issue. It has been tried. Every Workday customer with more than 500 employees has run "Workday for Managers" enablement at some point. The enablement does not stick. Six months after the training, manager usage of Workday is back to where it was before. The reason is not that managers are lazy. The reason is that the workflow is, by design, too long, too tab-heavy, and too forms-oriented for the work pattern of a modern hiring manager.
The Create Job Requisition flow, at a glance
Required fields
12–18
Across the canonical Workday workflow
Tabs
4–7
Job profile, location, comp, supervisory org…
Save progress
No
Hiring manager either restarts or delegates
A typical Create Job Requisition flow has between 12 and 18 required fields across 4 to 7 tabs. The fields ask for information the hiring manager does not have at hand without leaving the form (job profile codes, cost center IDs, location codes, supervisory organization references). The form does not save progress in a way the hiring manager trusts. If the hiring manager is interrupted, which they will be, they have to either delegate the saved form (which itself is a documented Workday admin headache) or restart.
Compare this to the experience the hiring manager has in literally every other tool they use. In Slack, a request is a sentence. In Linear, a ticket is a title and a description. In Notion, a page is a paragraph and a checkbox. The hiring manager is not a worse version of themselves in Workday. They are responding rationally to a workflow that was designed for a different kind of work.
The Workday requisition flow assumes that the person filling it out is the person who has all the information. It assumes that the person filling it out is paid to fill out forms. It assumes that the cost of getting the form right is borne by the same person whose time is being consumed.
None of those assumptions are true of a hiring manager in 2026. The hiring manager has the strategic context for the role and almost none of the operational details. The hiring manager is paid to ship product or close deals or build the team, not to fill out forms. The cost of getting the form right is borne by HR if the hiring manager gets it wrong, which means the hiring manager's rational incentive is to externalize the form to HR.
The structural fix is not better training. The structural fix is a workflow that meets the hiring manager where the hiring manager already is, which is Slack.
Time-to-rec, Workday-routed
9–14 days
From "decision to hire" to open rec in the ATS
Time-to-rec, TeamOhana
1–3 days
Same companies, same volume, faster front door
HRIS translation labor
0.5–0.8 FTE
$70k–$115k/yr of Slack-to-Workday translation
The simplest cost is time-to-rec. Across our customer base, the median time from "decision to hire" to "open rec in the ATS" at companies that route through Workday is between 9 and 14 business days. At companies that use TeamOhana as the front door, the same time-to-rec is between 1 and 3 business days.
Multiply that by the volume of requisitions a 1,500-person company opens in a year (typically 300 to 600) and the cost in deferred hiring becomes large quickly. Every two weeks of delay on an engineering hire at a Series D company is approximately $12,000 in deferred productivity. If your average requisition is delayed five business days by the form friction, and you open 400 requisitions a year, you are deferring approximately $1.2M of productivity per year on this one issue alone.
The second cost is the HRIS labor that absorbs the gap. The HRIS admin who is translating Slack messages into Workday forms is doing the work the hiring manager is supposed to do. At a 1,500-person company, this is approximately 0.5 to 0.8 FTE of HRIS labor permanently dedicated to translation. That is $70,000 to $115,000 of fully loaded labor cost per year being spent to bridge a gap the workflow created.
The third cost is what the HRIS admin is not doing. Every hour Christine spends translating Slack messages is an hour she is not spending on the strategic systems work she was hired to do. Skills inference. Internal mobility infrastructure. AI-readiness. The compounding cost of HRIS time stuck in the operational layer is the largest cost of all, and it is the hardest to put a number on because the counterfactual is invisible.
From the calls
"The business hate Workday and tend not to update it. Therefore you don't have a source of truth. You end up with multiple truths."
— Global Head of Recruitment Operations, 8,000-person dual-listed fintech
Failure mode 02
It is the second week of February at a 2,000-person AI infrastructure company. Last December, the company completed its annual planning cycle. The CFO and CHRO presented the headcount plan to the board. The board approved 612 net new positions for the year, distributed across functions, leveled and located.
By the second week of February, 47 of those 612 positions are already wrong.
Three positions have been re-leveled because compensation benchmarks shifted in January. Eleven positions have been relocated because the company decided to expand the Austin office and consolidate hiring out of New York. Eight positions have been re-scoped from individual contributor to manager because a planned reorganization in Engineering moved one level up. Twelve positions have been deprioritized because two products that were planned for H1 are now planned for H2. Thirteen positions have been added because a customer signed that wasn't in the original plan, and the customer's deployment requires Implementation Engineers.
None of these 47 changes have been reflected in Workday positions. They are reflected in three different Google Sheets, four Slack threads, and the memory of the head of People Operations, who is the only person who can reliably reconstruct the current state of the plan.
By April, 30 to 50 percent of the original plan will be wrong in the same way. By July, almost every position in the original plan will have been touched at least once.
This is failure mode two.
Plan rot, the math
Board-approved positions
612
Annual plan, approved December
Wrong by mid-February
47
Re-leveled, relocated, re-scoped, added, dropped
Wrong by April
30–50%
By July, almost every position has been touched once
Workday Position Management is supposed to be the canonical record of approved positions. The annual planning cycle produces a list of positions, the list is loaded into Workday, and Workday holds them durably with their metadata. Approvers can audit them. Recruiters can pull from them. Finance can forecast from them. The plan is in the system. The system is the source of truth.
The plan is in the system on day one. The plan diverges from the system starting on day two. By the end of the first quarter, the system is reflecting a plan that no longer exists.
The reason is that every change to a position requires the same workflow that nobody completes. To re-level a position in Workday, you have to initiate an Edit Position or a Change Job business process, route it through the same multi-tab form, secure the same approvals, and update the linked requisition if it exists. The work to keep Workday current with reality is roughly the same work as the work to put it there in the first place, and the same people are not doing it.
Instead, the changes happen in spreadsheets. Every company we have worked with has at least three spreadsheets running in parallel during any given quarter:
Each of these spreadsheets is updated faster than Workday is updated. Each of them is updated differently. Each of them diverges from Workday and from each other.
When the system of record diverges from the spreadsheets people actually work from, two things happen. First, people stop trusting the system of record. The first time a hiring manager pulls a Workday report and the report contradicts what they know about their own team, they learn not to trust the report. The second time, they stop pulling the report. The third time, they tell their HRBP that Workday is wrong and they need a spreadsheet.
Second, finance starts forecasting against fiction. The FP&A team's models are built off the position roster. The position roster is stale. So FP&A introduces compensating fudge factors. The most common one we have seen, in transcripts of customer calls, is the practice of automatically adding three months to the target start date of any position that has passed its planned start date without being filled. The fudge factor is invisible until the CFO asks why the forecast is consistently off by 20 percent on the upside.
The root cause is that Workday Position Management assumes a low rate of change. The form-and-approval workflow is sized for occasional updates, not continuous ones. When the actual rate of change is continuous, the workflow cannot keep up, and the spreadsheets emerge to fill the gap. The spreadsheets are not a failure of process discipline. They are a rational response to an unworkable workflow.
You can train people. You can write SLAs. You can enforce penalties. We have watched customers try all three. None of them work, because the underlying friction is not a discipline problem. It is a structural problem with the tool.
The first cost is forecast accuracy. When the plan rots, the forecast built on the plan rots with it. We see CFOs at mid-stage companies routinely miss headcount forecasts by 10 to 20 percent in either direction. At a 2,000-person company adding 600 heads at $180,000 loaded cost, a 15 percent miss in either direction is $16 million of either over-hire or under-hire.
The second cost is reconciliation labor. Every quarter, somebody has to bring the plan, Workday, the spreadsheets, and the ATS back into a single picture for the board deck. This is typically 40 to 60 hours of senior labor across HR, TA, and FP&A. At fully loaded $90 to $130 per hour, that is $4,000 to $8,000 per quarter, or $16,000 to $32,000 per year, in pure clerical reconciliation labor.
The third cost is decision latency. Leadership cannot make a decision against a plan they do not trust. We have watched executive teams defer decisions on whether to open or close a hiring tranche for three to four weeks because the underlying data could not be agreed upon. In a company growing at 30 percent year over year, three weeks of decision latency on a hiring tranche is material.
The fourth cost is morale. The HRIS team knows the system is wrong. The TA team knows. The hiring managers know. Everyone gradually loses confidence in the data and in the systems team that maintains it. We have seen HRIS leads quit over this specific dynamic. They were hired to run a system of record. They are spending their days defending the system of record from being abandoned. That is not a sustainable role.
From the calls
"35 open jobs. Every single one with a start date in the past. Finance has no idea when these will actually be hired."
— VP of Talent Acquisition, 8,000-person publicly traded fintech
Failure mode 03
It is the last week of March. A recruiter at a 900-person enterprise SaaS company has been working a Senior Engineering Manager role for six weeks. The role originally posted at L5 in Seattle. The hiring manager came back two weeks ago and asked to expand the role to L5 or L6 in any North American location. The recruiter updated the job posting in greenhouse. The recruiter updated the location parameters in greenhouse. The recruiter updated the comp range in greenhouse. The recruiter did not update the corresponding position in Workday.
A candidate accepts an offer on a Thursday at 4:30 p.m. for an L6 role in Toronto. The offer goes through the greenhouse approval flow. The candidate signs. greenhouse fires the hire-creation event to Workday on Friday morning. The hire-creation event fails because the position in Workday is still configured as an L5 in Seattle. The recruiter does not see the failure until Monday morning because she is out on Friday. The candidate's start date is supposed to be two weeks from the following Monday. The HRIS team now has to re-approve the position changes retroactively and re-fire the hire. The candidate's start date slips by a week.
This is failure mode three.
Workday and your ATS are supposed to be tightly integrated. Workday holds the position. The ATS holds the requisition. Changes made in one flow to the other. The candidate is hired in the ATS, which creates the worker in Workday, which fills the position. The cycle closes. The data is consistent across both systems.
The integration is one-way for most of its lifecycle and only briefly bidirectional at the moment of hire. Workday pushes the requisition to the ATS at the moment the position is approved. From that point until the moment the hire is created, the only data flowing between the systems is operational status updates (the requisition opened, candidates applied, an offer was extended). Substantive changes to the requisition's metadata, made by the recruiter in the ATS during the recruiting process, do not flow back to the Workday position. The Workday position stays at the state it was in at the moment of the original push.
The integration flow, as documented
Workday → push at approval → ATS ... recruiter edits level / location / comp ... ✕ no flow back Workday ... hire fires ... ✕ metadata mismatch → ticket
When the hire fires, Workday tries to match the hire to the position. If the position metadata in Workday still matches what the recruiter wrote in the ATS, the hire succeeds. If it does not, the hire fails, and your HRIS team gets a ticket.
This is not a Workday bug. It is the documented behavior of the standard integration. The standard integration was designed under the assumption that recruiters do not substantively change requisition metadata during the recruiting process. The assumption is wrong. Recruiters routinely change level, comp range, location, employment type, and a half-dozen other fields during the course of working a requisition. The integration was not built for that.
You can build a custom integration that handles the bidirectional sync. We will get to the cost of that in a moment. You can also build a manual reconciliation process where someone monitors changes in the ATS and replicates them in Workday. We have customers who have done this. It is, on average, 0.3 to 0.5 FTE of HRIS labor permanently dedicated to integration tending.
The integration is a point-to-point file or API exchange between two systems that were not designed to share a real-time data model. Workday's data model and your ATS's data model do not agree on what constitutes a "requisition." They do not agree on what level a position is at. They do not agree on what custom fields matter. The integration is an attempt to translate one model into the other, and translations of this kind are inherently lossy.
The standard Workday-to-greenhouse integration is called HRIS Link on the greenhouse side. It is documented and supported. It handles approximately 70 percent of the data flow your team needs. The remaining 30 percent requires either custom development or manual intervention.
The custom development option is Workday Studio. Workday Studio is Workday's proprietary integration framework. According to publicly available data from Kinnect, an independent Workday consultancy that specializes in headcount planning, a typical Workday Studio integration project costs $30,000 to $50,000 in initial implementation, plus $5,000 to $10,000 annually in maintenance. Those numbers are for a single ATS connection. If you need both Workday and your ATS to integrate with Adaptive or Pigment for the FP&A side, the multi-system custom integration projects can easily reach $150,000 to $300,000 over a two-year horizon.
Workday Studio integrations also require a specific category of developer: someone trained in Workday's proprietary framework, who understands both your Workday tenant and the target system's API. These developers are not cheap. They are not abundant. If they leave your company, the integration becomes harder to maintain. Every change to the integration requires the same specific category of developer.
Workday Studio build
$30k–$50k
Per ATS connection, upfront
Annual maintenance
$5k–$10k
Plus dedicated developer dependency
Broken hire syncs / quarter
4–7
2–4 hrs HRIS labor each, candidate start dates slip 3–10 days
The direct integration cost we have already established: $30K to $50K upfront, $5K to $10K maintenance, per ATS connection.
The hidden integration cost is what happens when the integration breaks, which is often. We have collected ticket data from several of our customers prior to TeamOhana. The median was approximately 4 to 7 broken hire syncs per quarter at a 1,500-person company. Each broken hire sync consumes 2 to 4 hours of HRIS labor to diagnose and resolve. That is 32 to 112 hours per year of HRIS labor on integration repair alone.
The candidate-experience cost is worse. Every broken hire sync delays a start date by 3 to 10 business days. Candidates who are about to start a new role and are told that their start date is slipping because of an "HR systems issue" lose trust in the company before they have started. We have heard of candidates rescinding acceptance over delays caused by failed hire syncs. The cost of losing a senior engineering candidate two weeks before a planned start is on the order of $20,000 to $40,000 in deferred productivity and re-recruiting cost.
The strategic cost is that the integration becomes a tax on every initiative that touches it. You want to add a new field to track skills? It has to flow through the integration. The integration has to be rebuilt. You want to add a new approval step? It has to be modeled in both systems. You want to add a new ATS for a regional acquisition? You need a new integration. Every change to your hiring infrastructure is a Workday Studio project.
From the calls
"A good quarter of our P-tech tickets are because the hire sync failed. We have other things to do."
— Data and Technology Specialist, 8,000-person fintech
Failure mode 04
It is the Friday before the quarterly board meeting at a 1,400-person B2B AI company. The CEO is preparing slides. One of the slides is "Headcount progress against plan." The slide needs three numbers: starting headcount, current headcount, and projected end-of-quarter headcount.
The CEO's chief of staff emails the head of FP&A, the head of People Operations, and the head of Talent Acquisition. Need consolidated headcount numbers for Tuesday's board deck. Please align and send back by EOD Monday.
The three leaders meet on Monday at 9 a.m. The head of FP&A has a number from Adaptive: 1,387 current, 1,425 projected. The head of People Operations has a number from Workday: 1,392 current. The head of Talent Acquisition has a number from her hiring tracker: 1,389 current, 1,431 projected. The four numbers are within 1.5 percent of each other, but they are not equal. The meeting takes ninety minutes. They eventually agree on 1,390 current, 1,428 projected. They cannot fully explain the differences. They do not have time to. The chief of staff puts the agreed numbers on the slide and moves on.
Four numbers at 9 a.m. on Monday
The board never sees the underlying disagreement. The CEO never sees the underlying disagreement. The CFO knows the underlying disagreement exists but trusts that it is "within the noise band." Six months later, the cumulative drift is no longer within the noise band, and someone has to explain to the board why the company's headcount is materially different from what the company said it was going to be.
This is failure mode four.
Workday is the source of truth for headcount. Workday integrates with your FP&A tool to feed forecast data. Workday integrates with your ATS to track open requisitions. The three systems are aligned. The numbers match. The reporting is consistent.
The three systems do not match, because each of them is updated at a different cadence by a different team using a different definition of "current headcount."
Workday updates whenever an HR transaction is processed: a new hire is confirmed, a termination is recorded, a transfer is approved. The cadence is event-driven and lagging. A termination that occurred on a Friday may not be reflected in Workday until the following Tuesday because the offboarding business process has not closed.
The ATS updates whenever a recruiter touches a requisition. The cadence is operational and trailing. An open requisition in the ATS does not always correspond to an approved position in Workday because requisitions sometimes get opened against placeholder positions during the rush of a quarter.
The FP&A tool updates whenever someone in finance rebuilds the model, which is typically once a month. The forecast in Adaptive on March 15 reflects the plan as understood on February 28 plus whatever ad-hoc changes have been keyed in since.
The three systems are correct by their own definitions. They are inconsistent with each other. When a leader asks "what is our current headcount?" the answer depends on which system you ask and what you mean by "current."
Compounding this is the practice of every team maintaining its own spreadsheet "to be sure." We have audited customer environments and found, in one case, fourteen distinct spreadsheets running simultaneously, each with a different version of the truth. The fourteen spreadsheets were not the work of fourteen unreasonable people. They were the work of fourteen reasonable people who had each been bitten enough times by inconsistent system data that they decided to maintain their own.
There is no single layer above the three systems that reconciles them. The reconciliation, when it happens, is done by humans on a calendar. The humans are accurate enough to keep the company running, but they are not accurate enough to produce a number that any two leaders would agree to without a ninety-minute meeting.
The structural fix is not to demand that everyone "use Workday as the source of truth." We have watched companies try this. It does not work because the systems do not produce the data at the cadence or in the form that the people working from spreadsheets actually need. The structural fix is a reconciliation layer that sits above the three systems and produces a single number, on demand, that everyone can agree to.
The most visible cost is the reconciliation labor. We have measured this in our customer base. At a 1,500-person company, total reconciliation labor across HR, TA, and FP&A averages 60 to 80 hours per month. At fully loaded $90 to $130 per hour, that is $5,400 to $10,400 per month, or $65,000 to $125,000 per year, of pure clerical labor doing work that should not need to be done.
The less visible cost is the loss of leadership trust in the data. Every time leadership has to spend ninety minutes reconciling four numbers before a board meeting, they lose a little more confidence that the underlying systems are working. The compound effect of that loss of trust is that, eventually, leadership stops asking the systems and starts asking the people. The systems become a backstop. The people become the source of truth. That is the inverse of how this is supposed to work, and it is what your HRIS team most fears.
The strategic cost is decision velocity. Companies cannot move quickly on workforce decisions when they do not trust their own workforce data. When the question "should we accelerate hiring in Q3" cannot be answered without a multi-day reconciliation exercise, the question gets deferred. The deferral costs more than the reconciliation. We have watched companies miss hiring windows by a quarter because the data underneath the decision was not trustworthy enough to act on.
From the calls
"100 different recruiters, 100 different spreadsheets, 100 different sources of truth."
— Global Head of Recruitment Operations, 8,000-person fintech
Failure mode 05
It is the second week of an internal audit cycle at a recently public software company. The auditor is reviewing the controls around compensation changes. She asks the HRIS lead for the documentation of how a specific role's level was changed in Q2 of last year. The role moved from L5 to L6 between April 15 and May 3. The auditor wants to see who requested the change, who approved it, what the financial justification was, and when it was implemented.
The HRIS lead opens Workday. Workday shows the position at L6, effective May 3, approved by the VP of Engineering. The auditor asks for the supporting documentation. The HRIS lead opens her email. The original request from the VP of Engineering is in Slack, not email. The HRIS lead opens Slack. The relevant message is from April 16. The VP of Engineering wrote: can we re-level the Staff Backend role to Principal? candidate I'm talking to is more senior than we initially scoped. The CHRO responded with a thumbs-up emoji. The CFO was tagged but did not respond. The change was implemented in Workday on May 3 by the HRIS team, citing "executive approval."
The auditor asks: where is the financial justification? Where is the comp committee review? Where is the documented approval from the CFO?
The HRIS lead does not have answers. She has a Slack thread, an emoji, and a change in Workday. The audit finding is a control weakness with a recommendation to formalize the approval process.
This is failure mode five.
Workday Position Management is supposed to be the audit-ready system of record for all position changes. Every approved change is captured with an approver, a date, and a justification. SOX-compliant. Auditor-friendly. Forensically reconstructible.
The system of record records the change. The system of record does not record the conversation that led to the change. The conversation that led to the change is the audit-relevant material. The conversation happens in Slack, email, hallway, or a meeting that was not recorded. The supporting documentation, if it exists, is scattered across systems your auditor does not have access to.
For private companies, this is uncomfortable but survivable. For public companies, it is a SOX control weakness. For companies preparing to go public, it is a problem that will compound through the S-1 process and surface in their first audit cycle.
The promise of an audit-ready system of record cannot be kept if the work that drives the changes happens outside the system of record. You can build the cleanest position management implementation possible, and the audit trail will still fail at the moment of inspection, because what the auditor wants is not the record. The auditor wants the reasoning behind the record, and the reasoning happened somewhere else.
The same structural problem we have been naming throughout: the system of record is downstream of the system of work, and the system of work has no audit infrastructure. The fix is not to push the work back into Workday. The fix is to build an audit-grade decision layer in the system of work, and let it feed the system of record once decisions are made.
The direct cost of a SOX control weakness is consultant-led remediation. We have heard customer figures in the range of $50,000 to $200,000 to remediate a single material weakness, depending on scope. If your auditor identifies position change controls as a weakness, expect the remediation cost to be at the upper end of that range, because the remediation requires changing both the process and the system.
The indirect cost is leadership distraction. A material weakness disclosure consumes audit committee attention, CFO attention, and CHRO attention. The cost of leadership attention on a remediation is high and difficult to quantify, but every public-company CFO we have spoken to has named it as one of the costs they worry about most.
The strategic cost is going-public readiness. Companies preparing for an IPO who do not have clean position change controls discover the problem during the S-1 process. The fix is then on a deadline, with auditor involvement, with limited time. We have watched companies push their IPO timeline by a quarter because of issues that were rooted in this specific failure mode.
From the calls
"Our SLA is 48 hours to get approval and posted. Finance is usually looking at the target start date that hiring managers are pulling out of nowhere and trying to validate it. So that's why there's a holdup."
— Head of Talent Acquisition, mid-cap technology company
If you read the five failure modes back to back, the same shape repeats. Workday Position Management makes a promise that depends on a workflow nobody can sustain at modern hiring velocity. The workflow leaks. The work moves outside the system. The system goes stale. The data degrades. The cost compounds.
The fix is not better Workday hygiene. We have watched twenty Workday customers attempt better hygiene. The hygiene initiatives run for six to twelve months and then fade. The structural problem is that the system was designed for a slower world, and you do not live in the slower world. No amount of training, SLA enforcement, or executive sponsorship can make a 2009 workflow run at 2026 speed.
The fix is a layer in front of Workday that runs at the speed of the actual work, and that feeds Workday the durable record once the work is done. We will get there in Chapter 5. Before we do, we are going to put a number on what the five failure modes cost in aggregate. The number is uncomfortably specific, and it is the most important argument in this guide for the CFO who is going to sign off on the change.
Chapter 04
It is 11:20 on a Tuesday morning. A CFO at a 1,600-person Series E logistics technology company is reviewing the Q1 operating expense variance with his VP of FP&A. The variance is $3.4 million over plan. The CFO knows where it is. People costs. The forecast assumed an average new-hire start date of mid-March across a tranche of 80 positions. The actual average start date was the first week of April. The variance is not from over-hiring. It is from forecast accuracy.
The CFO has been here before. Same variance, same cause, every quarter for the last four quarters. Each time, the explanation is a version of "the hiring plan changed, and the forecast didn't catch up." Each time, the variance is in the $2 to $5 million range. Compounded, that is $12 to $20 million a year of OpEx variance driven by a single category of structural error.
He does not have a name for the error yet. By the end of this chapter, he will.
This chapter puts a number on what the five failure modes cost. The numbers are illustrative for a typical 1,500-person Workday customer. Your numbers will be larger or smaller in proportion to your size, but the structure of the cost stack is the same.
Distributed across budget lines, which makes it invisible. Once you draw it together, the business case becomes obvious.
The cost most easily quantified is the cost of building and maintaining the integration between Workday and your ATS. The standard option is Workday Studio. The published figures, from Kinnect (an independent Workday consultancy that specializes in headcount planning) put a typical Workday Studio integration at $30,000 to $50,000 in initial implementation, plus $5,000 to $10,000 annually in maintenance. These figures are for a single ATS connection.
In practice, a Workday Studio integration for a mid-stage company is more expensive than the published baseline. The reasons are predictable. Custom fields proliferate. Multiple ATS connections (greenhouse for engineering, Ashby for sales, SmartRecruiters for contingent) accumulate. Workday Pro hours add up. Internal HRIS hours add up faster than that. A two-year total cost of ownership for a custom integration stack at a 1,500-person company typically lands between $150,000 and $300,000.
The non-cash cost is the developer dependency. Workday Studio integrations require Workday-trained developers. They are a narrow talent pool. They charge between $200 and $400 per hour. If you build a Studio integration and the developer leaves, you do not have a replacement on the bench. Every subsequent change runs through the same narrow channel.
The hidden integration cost is what happens when the integration breaks. Our customer data, before TeamOhana, showed 4 to 7 failed hire syncs per quarter at a typical 1,500-person company. Each failure consumes 2 to 4 hours of HRIS labor. That is 32 to 112 hours per year of HRIS labor on integration repair alone. At fully loaded labor cost of $90 per hour, that is $3,000 to $10,000 per year of pure repair work.
For the typical 1,500-person Workday customer, the all-in integration cost is between $50,000 and $80,000 per year, amortized.
The cost most visible to your operational teams is the labor that goes into reconciling Workday, the ATS, the FP&A tool, and the four to fourteen spreadsheets that supplement them.
We have measured this in our customer base. At a 1,500-person company, total reconciliation labor across HR, TA, and FP&A averages 60 to 80 hours per month. That includes weekly tracker updates, monthly forecast updates, quarterly board prep, and the ad-hoc reconciliations that happen whenever leadership asks a question the systems cannot answer cleanly.
At a fully loaded labor cost of $90 to $130 per hour (HR and TA on the lower end, FP&A senior labor on the higher end), that is $5,400 to $10,400 per month, or $65,000 to $125,000 per year.
This is the cost the HRIS admin feels most acutely. It is the cost the CHRO is least likely to see clearly, because the reconciliation labor is distributed across three functions and never shows up on a single budget line.
The cost most visible to the CFO is over-hire spend driven by inaccurate forecasting. When the position data is stale and the hiring plan is wrong, the forecast built on top is wrong. Companies plan and budget against a number that does not match the trajectory they are actually on.
We have data on this from companies that switched to TeamOhana. The typical pre-TeamOhana forecast accuracy on headcount is between 75 and 85 percent (in other words, a 15 to 25 percent miss on the forecast). After implementing a reconciliation layer in front of Workday, forecast accuracy moves to 92 to 97 percent within two quarters.
For a 1,500-person company adding 400 net new heads in a year at $160,000 fully loaded cost, the difference between 80 percent forecast accuracy and 95 percent forecast accuracy is approximately $9.6 million of either over-hire or under-hire on the year. Even if the miss is half over-hire and half under-hire, the cumulative dollar magnitude is on the order of $4 to $8 million per year for a company of this size.
Note that this cost is not "wasted." Most of the people hired in excess of plan are real employees doing real work. The cost is that the work they are doing is not what the company prioritized, and the budget envelope is exhausted ahead of schedule. For a public company, this surfaces as guidance miss. For a private company on the path to public, this surfaces as runway compression.
The over-hire cost is the largest line in the cost stack. It is also the most volatile to estimate, because it depends on factors outside the position management workflow itself. We use it as a rough order of magnitude, not a precise figure. The order of magnitude is what matters: for a 1,500-person company, this number is in the millions, not the thousands.
The cost that is hardest to quantify and ultimately the most important is what your HRIS lead is not doing while they are reconciling positions.
The HRIS lead at a 1,500-person Workday customer typically spends 40 to 60 percent of their week on operational tasks: integration tending, reconciliation, change request processing, audit response, training requests. Some of this is unavoidable. Some of it is the cost of the structural problem this guide is describing.
The 40 to 60 percent of their week that is consumed by operational tasks is not available for the strategic work the role was created to do. Skills inference. Internal mobility infrastructure. Career frameworks. AI-readiness audits. Workforce intelligence reporting. The next generation of People analytics. Every Workday customer we have spoken to has a list of strategic HRIS initiatives that have not been started because the HRIS lead is buried in operational work.
The compounding cost is hardest to put a dollar figure on because the counterfactual is invisible. We know what the HRIS lead is not building because they tell us. We do not know what those builds would have produced if they existed.
A reasonable lower-bound estimate: if your HRIS lead is paid $180,000 fully loaded and spends 50 percent of their time on work that should be automated or eliminated, you are paying $90,000 per year for that loss. The upper bound, which includes the strategic value of what they are not building, is several multiples of that number.
For a typical 1,500-person Workday customer, the annual cost of running Workday Position Management without a decision layer in front of it is approximately:
The headline number, conservatively stated, is between $4.2 million and $8.3 million per year of operating impact attributable to the five failure modes.
The most important thing about this number is not its precision. It is its existence. Most companies have never tried to compute it. The cost is real. It is distributed across budget lines, which makes it invisible. Once you draw it together, the business case for changing the architecture becomes obvious.
This is the chapter the CFO reads. The next four chapters are about what to do.
From the calls
"We put 250 headcounts too much in a location in the month of December. We realized we overhired by 250 people, which is not ideal. We hired nearly double the amount of people that we actually wanted to hire."
— Global Head of Talent Strategy, 8,000-person fintech
Chapter 05
It is the third week of an implementation at a 1,200-person fintech that recently moved its hiring infrastructure into a new architecture. The HRIS lead is on a call with her VP of FP&A. They are looking at a screen that, until eight weeks ago, did not exist at the company. The screen shows every approved position, every open requisition, every offer extended, every hire pending, and every backfill flagged. The numbers add up. The system that holds this view is not Workday, and it is not greenhouse. It is a layer that sits in front of both.
The HRIS lead says, I want to show you something. She clicks into a backfill request from an engineering manager that came through that morning. The request is for an L5 backfill at the same level as the terminating employee. The request was initiated by the engineering manager directly, in a workflow she completed in three minutes from her phone during a coffee break. The request was routed to the engineering VP for approval. The engineering VP approved it from his email on his way to a meeting. The request now sits at "Approved, ready for TA to push to greenhouse." The position in Workday has not been created yet, because the workflow has not pushed it. The greenhouse req has not been opened yet, because the workflow has not pushed it. The hiring plan reflects the approval. The forecast reflects the approval.
The HRIS lead says, This is exactly what we used to spend two days doing in Slack and Workday. The VP of FP&A says, And the forecast is already updated? The HRIS lead says, Yes.
That is the conversation we want every Workday customer to have.
This chapter describes the architecture that produces that conversation. The architecture has a name. We call it the front door.
The front door is not a replacement for Workday Position Management. It is a layer that sits in front of it.
Hiring managers, TA leaders, HR business partners, and Finance all transact in the front door. Requests originate in the front door. Approvals route through the front door. Changes propagate through the front door. Reconciliation happens in the front door.
Workday remains the system of record. The front door writes to Workday Position Management when a decision is made. The front door does not replace what Workday does. It feeds Workday what Workday needs, in the form Workday needs, after the work that actually drives the decision has happened somewhere built for it.
This is not a clever architectural metaphor. It is a literal description of how every successful customer of ours has architected their workforce planning since 2022. The pattern is consistent across companies of every size, in every industry, on every flavor of Workday tenant.
Figure 5.1 · The front door architecture
Four layers · one ID flows through all four
There are six objects that move through the architecture. Each has a durable identifier. Each has a lifecycle. Each crosses between two or three systems during its lifetime.
The six objects are:
Each of the six objects has a single identifier that flows through every system. This is the cardinal architectural property. The front door issues the identifier when the request is created. The identifier is used by Workday for the position, by the ATS for the requisition, by the FP&A tool for the forecast line, and by the audit trail for the documentation. Every system uses the same identifier. Reconciliation is automatic because the identifier is the same everywhere.
A 1,500-person engineering org has 47 open requisitions, 312 approved positions in this fiscal year's plan, 89 not yet started, 12 backfills in flight, and 4 internal transfers. The HRIS lead opens the front door and sees all of this on a single screen.
The CFO opens the front door and sees: $42 million in approved fully loaded annual cost across the plan, $36 million in forecasted spend through end of year, $6 million variance favorable, primarily driven by start date push-outs in Q4.
A hiring manager opens the front door and sees: my team has 7 open positions, 3 are at risk of missing target start date, 2 are critical priority, and the one I requested last week was approved yesterday and pushed to greenhouse this morning.
A recruiter opens the front door and sees: my queue, 18 active requisitions, sorted by priority, with target dates that have been auto-calibrated against my historical time-to-fill for similar roles.
The TA Operations leader opens the front door and sees: the full hiring plan, what is ready to hire versus what is still pending, what has been pushed to the ATS, what is in offer stage, and what has been hired in the last 30 days.
None of these people is looking at Workday directly. Workday is being updated in the background, in real time, with everything they are doing. When the auditor arrives, the auditor opens Workday and sees a clean record of every position and every change. When the FP&A team rebuilds the Adaptive model, the data flows automatically from the front door into Adaptive without manual reconciliation.
The system of work is happening in the front door. The system of record is happening in Workday. Both are working. Neither is being asked to do the other's job.
We are precise about what the front door is not, because the temptation to over-describe what TeamOhana does is real, and we want to keep this guide honest.
What the front door is not
The front door is not a replacement for Workday HCM. Your employees still live in Workday. Your org chart still lives in Workday. Your payroll still lives in Workday. Your job profiles, comp bands, supervisory orgs, and security model still live in Workday. None of that changes.
The front door is not a replacement for Adaptive or Pigment. Your FP&A team still models in Adaptive. They get clean data from the front door instead of from a stale Workday extract, but the modeling and forecasting capabilities of Adaptive are not being duplicated.
The front door is not a replacement for greenhouse, Ashby, or SmartRecruiters. Your recruiters still work in the ATS. They still source, screen, interview, and extend offers in the ATS. The integration to Workday now goes through the front door, but the recruiting work stays where the recruiting team is.
The front door is not a workflow engine you have to build from scratch. The approval policies are configurable but pre-built. The integrations are pre-built. The data model is pre-built. Implementation is six to eight weeks, not nine months.
The front door works because it respects the constraints of each system in the stack. Workday is left to do what Workday is good at: durable system of record. The ATS is left to do what the ATS is good at: candidate pipeline management. The FP&A tool is left to do what it is good at: financial modeling. The front door does the work none of them was built to do: be the place where the actual hiring decision lifecycle happens.
The most important property of this architecture is that it is reversible. If you implement the front door and a year later decide you do not need it, you can disconnect it. Workday will still have every position. Your ATS will still have every requisition. Your audit trail is preserved. You are not locked in.
This matters because every Workday customer we talk to is exhausted by long implementations. The promise of an architecture you can implement in eight weeks and reverse if it does not work is a profoundly different promise from the architecture conversations they have been having since 2018.
Workday customers occasionally ask: Can't we just use Workday Adaptive Planning as the front door? The answer is no, and the reason is structural. Adaptive Planning is a financial planning tool. Its design center is FP&A. Its primary users are finance analysts. Hiring managers do not use Adaptive. TA does not use Adaptive. HR business partners do not use Adaptive. Asking Adaptive to be the front door for the hiring decision lifecycle is asking it to be a tool it was not built to be, with users it was not designed for. This is the same category error that brought us here in the first place.
Some customers ask: Can't we just build this ourselves? The answer is technically yes, and we have seen it tried. Building the front door yourself means building the workflow engine, the approval policy model, the integration to Workday, the integration to your ATS, the integration to Adaptive, the data reconciliation layer, the user interface, the access control model, the audit trail, and the reporting. We have seen estimates from internal teams that ranged from $400,000 to $1.2 million over 12 to 18 months. We have not seen one that succeeded on its first try.
Some customers ask: Can we wait for Workday to build this? Workday's product roadmap is its own to set. Our observation, from inside the ecosystem since 2022, is that Workday is investing heavily in AI-driven analytics and skills inference and is not investing in fundamentally rethinking the requisition workflow or the integration architecture. We have no inside information. We have a long-term pattern. The pattern says you should not wait.
The day after the front door is live:
None of this requires a re-implementation of Workday. None of it requires changing your ATS. None of it requires building anything. It requires plugging in a layer that already does these things.
In the next chapter, we walk through what changes specifically for each role at the company, in the voice of that role. This is the chapter you forward to the colleagues who need to be convinced.
From the calls
"I want one front door. When I have a problem, I walk through that door. Not a door called Workday, not a door called SmartRecruiters. One door."
— Global Head of Talent Strategy, 8,000-person publicly traded fintech
Chapter 06
The architecture is the easy part to explain. The harder part is what changes for each specific person at the company once the architecture is in place. This chapter walks each role in turn, in language that role's incumbent would recognize as their own.
If you are reading this and you are one of these roles, this is your chapter. If you are reading this and you are evaluating whether to introduce the architecture, this is the chapter you send to the colleagues whose buy-in you need.
You stop being the human API.
The work you do today that is not strategic and is not what you were hired for, you stop doing. The translation of Slack messages into Workday forms goes away. The reconciliation of position data across Workday, the ATS, and four spreadsheets goes away. The chase to update target start dates that hiring managers chose at random goes away. The integration repair work that ate two days per quarter goes away.
What replaces it is the strategic work you were hired to do. Skills inference projects. Internal mobility infrastructure. Career framework rollouts. AI-readiness audits. The next generation of People analytics. The work that requires your judgment, your relationships, and your deep knowledge of how your company actually operates.
You do not learn a new system in a deep way. The front door is configured for your specific Workday tenant during the six-week implementation by a TeamOhana solutions architect. You contribute two to four hours of admin time across the first two weeks. After that, the system is yours to administer, with documentation and a customer success partner who picks up the phone.
The audit trail you wished Workday produced is the audit trail the front door does produce. Every approval, every change, every comment, every comp impact, captured against a single position ID that flows everywhere. The next time an auditor asks for the documentation of a Q2 re-level, you click into the position, click on history, and the auditor sees what happened. You do not open Slack. You do not search email. The system has it.
The integration tickets stop. Hire syncs that used to fail because the position metadata had drifted now succeed because the position metadata is current. Your queue of open tickets, the queue you have been managing since the day you started, gets shorter, then stays shorter.
You stop having to defend the system of record. The system of record has stopped being wrong.
You get hiring managers who actually engaged in the headcount process, instead of hiring managers who tolerate it.
The data underneath your headcount narrative becomes data you can defend in any executive meeting. The board deck no longer requires a ninety-minute pre-meeting between FP&A, People Operations, and TA to agree on the numbers. The numbers agree because they come from a single layer that fed all three systems.
Your HR business partners get back to being business partners. The HRBP who is currently spending half their week chasing position updates and reconciling spreadsheets has that half a week returned to them, for the strategic partnership work that is the actual job of an HRBP.
Your TA function shifts from delivery to strategy. When the operational layer is clean, TA leaders can have the conversation they have been wanting to have with the business: are we hiring the right roles, at the right level, in the right places, in the right sequence? That conversation has been impossible to have in the past because the data underneath it was untrustworthy. Now it is the conversation.
The SOX and audit conversation gets shorter. Your auditors stop flagging position management as a control concern. You stop spending CFO and audit committee attention on something that should be a back-office process.
You stop hearing about Workday in negative terms. The complaint queue you receive from VPs about "the system is broken" gets shorter. The system is not broken. The system was being asked to do a job it was not designed for. You have stopped asking it to do that job.
Your headcount forecast updates with the business, not with the calendar.
The 15 to 25 percent forecast variance that has been a chronic feature of your quarterly results goes away. We are not claiming forecast variance disappears. There will always be a forecast variance. But the variance moves from 15 to 25 percent down to 3 to 8 percent within two quarters of implementation. The difference is the difference between a public-company narrative that says "we are managing headcount carefully" and a public-company narrative that says "we are missing on people costs again."
The over-hire scenario where you discover at the end of Q1 that you have already exhausted your annual hiring budget stops happening. The front door tracks dollars, not just heads. Every approval shows you the budget impact. Every change shows you the variance. The CFO cockpit you have wanted to have on headcount is the cockpit your CHRO and HR team see by default.
Your audit responses get faster. SOX inspection of position changes becomes a one-screen exercise instead of a multi-system scavenger hunt. Your internal audit team starts looking forward to position controls instead of dreading them.
Adaptive (or Pigment, or Anaplan) becomes more accurate, not redundant. The front door integrates with your FP&A tool and feeds it the live picture instead of a snapshot. Your finance team stops manually rebuilding the headcount roster every month. The work they were doing on roster maintenance turns into work on scenario modeling, which is where their value is highest.
The 60 to 80 hours of monthly reconciliation labor that is being absorbed across HR, TA, and FP&A becomes 0 to 10 hours of exception handling. That is roughly $90,000 per year of clerical labor returned to the budget. It is not the headline number, but it is the most consistent number across our customer base.
You have a single source of truth and you can trust it.
The hiring plan you maintain in spreadsheets is now the hiring plan everyone else is also looking at. When a hiring manager asks you "where is my req?" you do not have to assemble the answer from four systems. The hiring manager looks in the front door and sees their req. They stop asking you.
The "ready to hire" gate is real. You and your team control the moment when an approved position becomes an open req in the ATS. You can keep approved positions in the plan without flooding the ATS with reqs you are not actually ready to work. Your recruiter capacity, for the first time, is something you can manage against your incoming flow rather than against an arbitrary list.
The target start date conversation changes. The dates hiring managers chose at random in January are replaced by AI-recommended target dates based on your real historical time-to-fill for similar roles. You can still override them. The override is a deliberate decision instead of an arbitrary one. Your finance team stops using "plan plus three months" as a default because the underlying dates are now defensible.
The cross-team handoff between TA and HR business partners becomes cleaner. Backfills, internal transfers, position changes, and reorgs all flow through the same workflow. The HRBP and the TA Operations team are working from the same data with different views. The handoff is no longer a Slack thread.
You become a strategic partner to the business. The conversations you can have with hiring managers move from "did you fill out the form correctly" to "let's talk about how to sequence your hiring against your roadmap." That is the conversation TA leadership has wanted to have for years. It becomes possible when the operational layer is no longer consuming all your attention.
The headcount roster stops being your problem.
The monthly rebuild of the headcount roster in Adaptive stops being something your team does manually. You stop pulling Workday extracts. You stop reconciling against the ATS. You stop adjusting for known terminations. You stop plugging in target start dates against the plan. The data flows. You spend the saved time on the modeling work that requires your judgment.
The CFO cockpit you build becomes accurate. The headcount line in your operating expense forecast updates with reality instead of with a monthly snapshot. The variance analysis you run each month is variance against a live picture, not against stale data.
The forecast accuracy improvement is measurable. From 75 to 85 percent (where most companies sit before the architecture is in place) to 92 to 97 percent (where our customers sit within two quarters). That improvement compounds in board credibility, market credibility, and CFO credibility.
The relationship with TA and HR gets better. When the data is shared and clean, the meetings between FP&A, TA, and HR stop being about reconciliation and start being about decisions. The three teams begin to feel like one cross-functional capability instead of three rival sources of truth.
You request headcount the way you request a Linear ticket.
You open a request. You fill in the strategic context: what is the role, what level, where, when do you need them. The front door fills in the operational details from your job catalog. You hit submit. You go back to your interview, your sprint planning, your demo, your customer call. The request routes for approval through your VP, your HRBP, and FP&A on the rules your company has configured. You get a notification when it is approved. Your recruiter starts work.
You see your hiring plan when you want to. You open a dashboard that shows your team's open headcount, what is in progress, what is at risk, and what has been hired this quarter. You do not open Workday. You do not chase HRBP for status updates. You do not maintain your own spreadsheet to know where things are.
When the role needs to change, when you decide to up-level, add a different location, or push the start date because Q3 priorities shifted, you initiate the change from the same place you initiated the original request. The change routes for re-approval. The downstream systems update automatically.
You stop being the source of the chaos. The Slack message you would have sent to your HRBP becomes a structured request. The HRBP stops translating. The TA team stops asking you to confirm the level. The recruiter stops working from a stale rec. The candidate's start date does not slip.
You did not learn a new system. The system was designed to look and feel like the tools you use every day. You learned it in five minutes.
These six roles all run on the same front door. Each sees a different view. Each has different permissions. Each is working on the same underlying data. The shared data is what removes the friction that has been the entire subject of this guide.
In the next chapter, we describe what it actually takes to put this in place at your company. We are honest about it, because the last thing you want to hear is another nine-month implementation story.
A note from the field
"I joined this company a year ago thinking I was going to do strategic HR. I spend half my week patching positions in Workday."
— HRIS Lead, public B2B SaaS company
Chapter 07
Every Workday customer we talk to has the same fear. They have lived through one Workday implementation. They are not interested in another one. The fear is rational. The fear is also misplaced for what we are describing.
This chapter walks the actual implementation. We are honest about what it takes and honest about what it does not take. The pattern is consistent across our customer base.
A typical implementation runs six to eight weeks from contract to live. Two to four hours of HRIS admin time is required across the first two weeks. After that, the work is done by a dedicated TeamOhana solutions architect who is assigned to your account for the full implementation and stays as your primary contact afterward.
You do not need a consulting firm. You do not need a Workday Studio developer. You do not need a separate integration project. You do not need to retrain your HR team on a new system. The implementation is designed for the resource constraints of a mid-stage company that has finite HRIS bandwidth.
Figure 7.1 · The 8-week implementation
The solutions architect connects to your Workday tenant via API. We do not require a file-based integration. We do not require Workday Studio. The Workday API connection is configured in 2 to 4 hours of HRIS admin time, working with your existing Workday administrator credentials.
The data we pull from Workday on the initial connection: supervisory orgs, cost centers, locations, job profiles, comp bands, employees, position roster, termination history. We do not write back to Workday at this stage. The first two weeks are read-only. You can verify the data we are seeing matches the data you expect.
In parallel, the solutions architect connects to your ATS, whether greenhouse, Ashby, or SmartRecruiters. The ATS integrations are pre-built and require a comparable 1 to 2 hours of admin time on your ATS side. We pull the open requisition roster, custom fields, and metadata mapping.
Finally, if you use Adaptive, Pigment, or Anaplan, the solutions architect configures the outbound feed to your FP&A tool. This is the cleanest integration of the three and typically requires the least admin time on your side.
The most important decision in the implementation is how the front door interacts with Workday Position Management. There are two patterns. Your solutions architect helps you pick.
The first pattern is to create positions in Workday at the moment of approval in the front door. The front door issues the identifier, writes the position to Workday with all its metadata, and synchronizes from that point forward. This is the cleanest pattern for companies that want every approved position to immediately exist in Workday as a durable object.
The second pattern is to create positions in Workday at the moment of hire. The front door holds the approved request as a "pending position" until the candidate accepts an offer, at which point the position is created in Workday and the candidate is matched against it. This is the cleaner pattern for companies that have a lot of approval churn early in the year and prefer not to create positions that may be re-scoped or cancelled before hiring.
Both patterns are supported. Most of our customers start with the second pattern and migrate to the first within a year as their approval discipline tightens.
Your approval policies are configured against your actual rules. Different routing for new hires versus backfills versus level changes versus high-comp roles. Different approvers based on cost center, location, employment type, level threshold, and any other dimension you care about.
We have a default starter policy library based on what we have seen work at companies of your size. You customize from there. The customization is done in a configuration interface that your HRIS lead can manage directly without engineering involvement.
Access control follows your Workday hierarchy by default. Hiring managers see only their own org. HR business partners see the cost centers they support. FP&A sees the budgets they own. Finance leadership sees the full picture. Your CHRO sees everything. The access model is configurable down to the cost center, but you almost never need that granularity.
HR business partners, TA Operations, and FP&A go live first. They are the personas with the highest daily contact with the system. Training is 90 minutes of synchronous content plus a short documentation library. Most users are productive within their first session.
Hiring managers come next, in waves. We recommend a staged rollout: one or two departments first, then the rest of engineering, then the rest of the company. The full hiring manager rollout typically completes 30 to 60 days after the initial go-live. The staged approach gives your HR and TA teams time to handle the questions that emerge in the first wave before the full company is on the system.
Training for hiring managers is 20 minutes of self-paced content. The interface was designed to require almost no training. The actual learning happens in the moment of use. The hiring manager opens the system, requests a head, and the system guides them through the workflow.
You go live with the first wave. Your dedicated solutions architect monitors the system for the first 30 days, available on Slack or email for any question. The first 30 days surface the issues that always surface in any new system rollout: a hiring manager who cannot find their org, a cost center that is mis-mapped, an approval rule that needs adjustment.
By day 60 to 90, the system is steady-state. Your HRIS lead is administering it. Your hiring managers are using it. Your audit trail is clean. Your FP&A team is forecasting from live data.
We do not promise that the implementation will go perfectly. Implementations are software projects. Software projects have unexpected issues. Yours will too. We promise that the issues will be small, surfaced quickly, and resolved by a solutions architect who has been through this implementation many times before.
We do not promise that hiring managers will love the system on day one. Some will. Some will resist. The change management work is real. We support it with playbooks, communication templates, and the dedicated solutions architect, but the executive sponsorship has to come from your CHRO or VP of People. We can build the tool. We cannot land the change for you.
We do not promise that your forecasting accuracy improves on day one. The improvement comes within two quarters as the underlying data cleans up and your forecast discipline starts to compound. The number we cite (75-85 percent baseline accuracy moving to 92-97 percent) is observed at two quarters post-implementation.
The implementation is additive. The risk is bounded. The reversal path exists if you ever needed to use it. None of our customers has.
From the calls
"The implementation timelines we're looking at, I just wanted to double-check. Six to eight weeks? That's not a Workday implementation."
— VP of Finance, Series E logistics technology company
Chapter 08
You have read seven chapters by this point. You have stayed with us through the diagnosis, the cost stack, the architecture, the persona impact, and the implementation reality. We have earned the right to make the bigger argument.
The bigger argument is this. Headcount is the first decision surface that the system of record cannot govern alone. It is not the last.
Compensation cycles. Career frameworks. Workforce composition. Reorgs. Internal mobility. Skills inference. The composition of work between humans and AI agents. Every one of these is a decision surface that today runs in Slack threads and spreadsheets and ends up reflected in Workday after the fact. Every one of them has the same shape as the headcount problem we have been describing for the last seven chapters. The system of record records the decision. The system of work has nowhere to make it.
Workforce planning will not be the last argument we have with the architecture of HR systems. It is the first one where the case is unambiguous, the cost is measurable, and the alternative is available. Once you have the front door for headcount, you have the underlying architecture for everything that comes next.
In the next eighteen months, the most important workforce decision your company will make is not how many people to hire. It is how to compose the work itself.
What work should be done by full-time employees. What work should be done by contractors. What work should be done by AI agents. What work should be eliminated. What work should be re-organized across different teams. The answer to each of these questions has to be made for every team, for every project, every quarter.
This decision is not a Workday decision. Workday will eventually record the answer. The answer itself will be made in Slack, in offsite conversations, in the executive standup. The decision surface for work composition is the same decision surface as the front door we have been describing. It is the system of work for workforce capital, not just for headcount.
The companies that figure this out first will operate on a different cost basis than the companies that do not. We do not believe this is a small claim. We believe it is the central claim about HR architecture for the next decade.
The technical name for what the front door produces is a Workforce Decision Record. Every decision about composition becomes a record: a new hire, a backfill, a re-level, an internal transfer, a contractor engagement, an agent deployment. The record has an identifier. The record has a justification. The record has an approver. The record carries the budget impact, the timing, the rationale. The record persists.
The Workforce Decision Record is what the system of work needs to produce. The system of record (Workday) needs to consume it. The audit trail consumes it. The forecast consumes it. The downstream operational systems consume it.
We have been building the infrastructure for the Workforce Decision Record since 2022. The infrastructure starts with the headcount lifecycle, which is the problem this guide is about. The infrastructure extends to compensation, career, composition, and the full lifecycle of workforce capital. The headcount front door is the first surface. It is not the last.
If a portion of your work is going to be done by AI agents in the next five years (and it is, whether you have a clear plan or not), the question of how you record that work, govern that work, and align that work to your existing workforce becomes urgent.
Today, agent deployments at most companies are happening below the line. An engineering team adopts a coding agent. A marketing team adopts a content agent. A customer success team adopts a deflection agent. Each adoption is a workforce decision. None of them is being recorded in Workday because Workday has no model for non-human labor.
The Digital Labor Registry is the architectural construct for recording, governing, and aligning agent labor with human labor. It is the next layer of the system of work, beyond the front door for human hiring. Like the front door, it is upstream of Workday. Like the front door, it produces records that flow downstream.
We mention it here not to pitch it but to give you the frame. The argument of this guide is about Workday Position Management today. The argument is part of a larger argument about how workforce capital is managed in the agentic enterprise. The companies that solve the headcount front door first will have the architectural foundation for everything that comes next.
Three forces converged in 2026 that make this the right moment to act.
The first is hiring volatility. The companies that learned to plan annual headcount in 2022 are operating in 2026 markets that re-forecast quarterly. The static plan does not work anymore. The system that holds it has to change with it.
The second is the consumer-grade UX expectation. Every hiring manager who runs their life in Slack, Notion, and Linear has been waiting for the rest of their work tools to catch up. The patience has run out. The hiring manager who refuses to fill out a Workday form is not being unreasonable. They are reflecting a generational shift in software expectations that you cannot reverse.
The third is the public-market scrutiny on G&A spend. CFOs reporting to public markets cannot tolerate the over-hire variance that Workday Position Management produces in practice. The cost of the gap is now too visible to be absorbed.
You can wait. The cost of waiting is the cost we computed in Chapter 4. Most of our customers reach the decision point through a specific moment: a SOX finding, a forecast miss, a board question that could not be answered, a key HRIS lead who threatened to quit, a candidate whose start date slipped, a re-org that revealed the position data was three months behind reality. Each of these moments is the moment the cost of doing nothing becomes visible.
We are not arguing you should act because we want you to buy our software. We are arguing you should act because the cost of not acting is real and you are paying it today, whether or not you have named it.
A note from the field
"What started as a position management problem ended up being a strategic conversation about how our whole company makes workforce decisions. We didn't know that's what we were buying when we bought it. It's what we got."
— CHRO, 2,400-person publicly traded SaaS company
Closing
The argument of this guide is one sentence: Workday Position Management is correct in theory and brittle in practice, and the gap between the two is now where every fast-growing company's hiring chaos lives.
The path out of the gap is one architectural change: a front door layer that sits in front of Workday Position Management, where hiring managers, TA, HR business partners, and Finance all transact, and that writes to Workday once decisions are made.
The implementation is six to eight weeks. The HRIS admin commitment is two to four hours. The reversal path exists. The risk is bounded.
The cost of doing nothing is between $4.2 million and $8.3 million per year for a typical 1,500-person Workday customer, distributed across integration cost, reconciliation labor, over-hire variance, and strategic opportunity cost.
If you are the HRIS lead or HR systems lead who has been forwarding this guide chapter by chapter, you have already made the case. The next step is to bring your CHRO and CFO into a 30-minute conversation about the architecture, with the diagram from Chapter 5 in front of them. We can do that conversation with you, or you can do it without us.
If you are the CHRO or CFO who skimmed the executive summary and read Chapters 4, 5, and 6, the question is not whether to fix the gap. The question is whether you fix it before or after the next forecast miss.
If you are the TA leader or FP&A lead who was forwarded this guide by someone above you, your job is to make sure the architecture conversation happens with the right context. Use Chapter 3 as your starting point. Use Chapter 6 as the persona-specific argument.
Three concrete actions, in increasing order of commitment.
Read more. Subscribe to TeamOhana's field notes. We publish a numbered series of operating playbooks for workforce intelligence, written for the same audience as this guide. The field notes go deeper on individual topics: scenario planning, the budget envelope, the digital labor mix, the joint motion between CFO and CHRO.
Get the implementation worksheet. We publish a one-page checklist of questions every Workday customer should be able to answer before evaluating TeamOhana. It is not a sales tool. It is a diagnostic tool. If you can answer the questions cleanly, you may not need us. If you cannot, you will know exactly what is broken.
Book a 30-minute architecture review. A live conversation with a TeamOhana solutions architect about your specific Workday tenant, your specific ATS, your specific FP&A stack, and what the front door would look like in your environment. We do not ask for an RFP. We do not require a procurement process to begin. We require 30 minutes.
The front door exists. The implementation is finite. The cost of waiting is real. The companies that act first will operate on a different cost basis than the companies that do not.
You know what your week looks like next Monday morning. You can run it again, or you can change the architecture underneath it.
— The TeamOhana team
A live 30-minute review with a TeamOhana solutions architect. Your specific Workday tenant, your specific ATS, your specific FP&A stack. No RFP required.
Appendix A
A diagnostic for your existing Workday Position Management environment. Answer each question honestly. The questions you cannot answer cleanly are the ones the front door architecture would resolve.
If you can answer 18+ of these cleanly: your environment is in better shape than 80 percent of mid-stage Workday customers. The front door architecture may not be your highest priority.
If you can answer 12 to 17 cleanly: your environment is at the median. The cost of the gap is real but not yet acute. You are likely within 12 months of one of the trigger events we describe in Chapter 8.
If you can answer fewer than 12 cleanly: the trigger event has probably already happened. The cost of the gap is acute. Implementing the front door is one of the highest-leverage architectural changes available to you.
Appendix B
This guide is built on five categories of source material.
Primary research from TeamOhana customers. Call transcripts and ROI data from active customers in the Workday ecosystem, including companies of 500 to 10,000 employees across financial services, technology infrastructure, software, life sciences, and gaming. Quotes are used with permission where attributed and composited where anonymized.
Third-party Workday community sources. Workday training documentation from public university and enterprise customers, including procedural documents for the Create Job Requisition workflow, Position Management lifecycle, and Workday Studio integration patterns. These are public documents and demonstrate the workflow complexity from Workday's own materials.
Independent Workday consultancy data. Cost figures for Workday Studio integration projects are drawn from publicly available analysis by Kinnect (kinnectx.com), an independent Workday consultancy specializing in headcount planning. The published figures of $30,000 to $50,000 for initial implementation and $5,000 to $10,000 for annual maintenance per ATS connection are corroborated by our own customer accounts.
Industry pattern data. Forecast accuracy figures, reconciliation labor estimates, and over-hire variance figures are aggregated across the TeamOhana customer base and cross-referenced against published industry analysis from Bersin, Gartner, and Forrester on workforce planning operating costs.
Workday's own marketing materials. We have referenced and contextualized claims from Workday's own product marketing on Workday Adaptive Planning, Workforce Planning, and Headcount Cost Planning. These claims are quoted accurately and assessed against the lived experience of Workday customers we have worked with.
The guide makes no factual claim that cannot be supported from one of these five categories. Direct customer attribution is available on request and under appropriate NDA.
End of guide
