Governance without bottlenecks: how Slack-based approvals change headcount management

Every company has a version of this story. An org leader needs to open a role. They send a Slack message to their HR business partner. The HRBP sends it up to finance. Finance sends it to the CFO. Someone approves it verbally in a standup. Three weeks later, recruiting asks if the role is approved. Nobody can find the original message.

That is not a people problem. That is an infrastructure problem. And it shows up in growing companies with a surprising regularity, even those that already have an HRIS, an ATS, and an FP&A platform in place.

Key takeaways

• Verbal approvals, Slack pings, and Google Docs threads are the de facto approval infrastructure at most mid-sized companies
• The absence of a structured approval layer creates bottlenecks, audit gaps, and conflicting numbers between Finance and HR
• A single leader becoming a manual checkpoint for every headcount decision is a structural problem, not a management one
• Slack-native approvals can eliminate the friction without requiring hiring managers or approvers to adopt a new tool
• A complete audit trail covering who requested, who approved, and what changed is the foundation of compliant, defensible headcount governance

Why does approval authority always end up with one person?

When a company lacks a structured approval system, approvals flow toward whoever is most organized and most trusted. That person becomes the de facto gateway for every headcount decision. Not because they volunteered, but because someone has to do it.

At a UK-based software company, their SVP of People had become exactly that bottleneck. Before approving any new headcount, she had to manually investigate the provenance of each open position: was it a net new hire, a backfill, or the result of a chain of internal movements tracing back to a single approved headcount from months ago? That manual investigation happened every time, for every role.

It was not a failure of process design. It was the absence of one. Without a system that owns the approval chain, the most responsible person in the room gets stuck doing the work a system should do.

What is actually wrong with Slack approvals?

The issue is not that companies use Slack for approvals. The issue is that Slack was designed for conversation, not for governance. When an approval happens in a Slack thread, several things fail simultaneously.

There is no audit trail that can be reliably reconstructed months later. There is no structured record of what was approved versus what was merely discussed. There is no way to enforce that the right people approved in the right sequence before a requisition was opened in the ATS. And there is no mechanism for flagging when a change occurs post-approval that would require re-approval.

A people ops leader described this plainly: they did not have a real chain of events they could follow from one system to another. Approvals lived in Slack. Changes happened in the ATS. Nobody was connecting them.

What does a structured approval system actually look like?

A proper headcount approval system has three non-negotiable properties.

First, every request originates in a single system. Not an email, not a Google Form, not a Slack message. A structured form that captures the role, level, location, compensation estimate, target start date, and business justification before the request enters any approval queue.

Second, the approval chain is configurable and enforced. Some roles route to a department head and then finance. Others route directly to finance. Backfills may have a lighter approval path than net new headcount. The rules are defined once and applied consistently, not left to memory or institutional knowledge.

Third, approvers are met where they already work. Requiring every hiring manager and department head to log into a new platform to approve a single role creates friction that kills adoption. The most effective implementations bring the approval notification directly into Slack, where approvers can review all the relevant details and click to approve without ever leaving the conversation they were already in.

That Slack notification is not a replacement for the platform. It is an entry point into it. Every approval, denial, and comment still flows back to the system of record. The approver is working in Slack. The audit trail is building automatically in the background.

Does multi-layer approval work natively in Slack?

Yes, and this is where the design matters. A first-line manager approves a headcount. That triggers a notification to the VP. The VP approves. That triggers a notification to finance. Each approver in the chain only receives their notification after the previous step is complete, or you can configure parallel approvals if all parties need to weigh in simultaneously.

A finance leader at a UK-based software company specifically asked whether multi-layer approval could work in Slack so that the first level of approval happens in Slack and then routes to the next level, also in Slack. The answer is yes. Each sequential approver gets their own notification with the full context of the request, the compensation, the justification, and any comments the previous approver left.

What happens when something changes after approval?

This is where most informal approval processes completely break down. A role gets approved in January for a Q2 start. In April, the hiring manager wants to up-level the role, change the location, or push the start date. In a Slack-based system, that change is a new message thread that may or may not reference the original approval.

A proper system treats post-approval changes the same way it treats the original request: as a structured change request that routes through the appropriate approval flow before any downstream system is updated. The key principle is that the approval record always reflects the current state of what was approved. If a role was approved at a certain comp midpoint and is now being offered above it, the variance is captured and visible to finance, with a record of who authorized the change. For how this connects to budget variance tracking, see our full guide on what finance actually needs.

What does this mean for hiring speed?

The paradox of building more governance is that it can actually accelerate hiring. When approvals are informal, they stall. An org leader is not sure if their Slack message was seen. Finance is not sure if the role was approved or just discussed. Recruiting is waiting for a signal that nobody has officially sent.

When approvals are structured and Slack-native, the time from request to approval decision can compress dramatically. Approvers see the notification immediately. They have all the information they need to make a decision without going back to the requestor. They approve with one click. The next step in the chain triggers automatically.

One people leader described the downstream cost of slow approvals clearly: a candidate had been lost because the org leader could not confirm the role was open when the candidate was ready to move. The role had been discussed and informally agreed to. But the formal approval had not been obtained. By the time it was, the candidate had accepted another offer.

The audit trail as a governance asset

An often-overlooked benefit of a structured approval system is the institutional memory it creates. Twelve months after a hiring decision, it is possible to reconstruct exactly what was approved, at what compensation, with what justification, by whom, and when.

The shift from informal to structured approvals is ultimately a shift from hoping governance happens to knowing it happens.

See how TeamOhana connects your headcount plan to every system your team uses. Book a demo to see what a purpose-built governance layer looks like.

Patterns cited in this article are drawn from TeamOhana's recent conversations with Finance, HR, and People Operations leaders across companies ranging from 300 to 3,000 employees. All references are anonymized and paraphrased.