Over the past three years, HR leaders have repeatedly been offered similar solutions: implement a chatbot or copilot and expect increased productivity. However, these tools have largely delivered incremental improvements in drafting rather than true transformation.

A significant change is now underway that will fundamentally reshape the HR function.

Agentic AI does not wait for a prompt. It watches for a trigger, decides what needs to happen next, and carries out the work across the tools your team already uses, from the applicant tracking system to payroll to Slack. Instead of a single smart assistant, you get a small workforce of specialized agents handling recruiting, onboarding, compliance, and employee service in parallel. That is the shift this article is about: from AI that helps a person do a task, to AI that runs the task on its own and simply reports back.

Assistants Answer Questions. Agents Get Things Done.

The easiest way to see the difference is to compare what each one does when nothing prompts them.

A generative AI assistant sits idle until someone types a question. Ask it to draft an offer letter, and it drafts one. Ask it nothing, and it does nothing.

An agentic system behaves more like a quiet coworker who never clocks out. It notices that a candidate pipeline has stalled for eight days, checks why, and either nudges the recruiter or reschedules interviews on its own. It notices a payroll anomaly before finance does. It notices that engagement scores dropped in one region and flags it to the HR business partner with a summary of what changed.

This is not automation in the old sense, where a system follows a fixed script. Agentic AI reasons through exceptions. It decides which of several possible actions makes sense given the situation, then takes that action, and only loops in a human when the stakes or ambiguity call for it.

Where This Is Already Showing Up

This is not a five-year-out concept. It is running in production at companies right now, and the results are concrete enough to plan around.

Recruiting has become an orchestrated pipeline rather than a series of manual steps. An agent can draft a job description from a workforce plan, post it across boards, screen incoming resumes against a skills rubric, rank the shortlist, and negotiate interview times directly with candidates and hiring managers. Recruiters step in for the conversations that actually need a human voice, not the calendar tetris around them. Healthcare organization Wellstar reported that an agentic assistant automated thousands of routine account unlocks and cut internal approval times from several days down to about ninety minutes, freeing staff for higher-value work.

Onboarding has quietly become a coordination problem that agents are well suited to solve. When an offer is accepted, one trigger can set off a chain: provisioning system access, ordering equipment, enrolling the new hire in the right learning paths, and notifying IT, facilities, and the hiring manager, all without someone manually checking five different systems.

Compliance monitoring is moving from a once-a-quarter audit to something closer to continuous coverage. Picture a state changing its family leave rules. An agent tracking regulatory feeds can catch the update within hours, compare it against the company’s current policy, flag the exact clause that needs to change, and hand HR and legal a summary along with a drafted revision, rather than someone discovering the gap during an audit months later.

Employee service is where the volume gains are hardest to ignore. Gartner has tracked HR’s AI adoption climbing from about 19 percent in 2023 to roughly 61 percent by 2025, and a large share of that growth is in service delivery: agents triaging tickets, answering policy questions, updating records, and escalating only the cases that genuinely need a person.

PwC’s analysis of HR sub-processes across the full hire-to-retire lifecycle found that agents can now handle or assist more than half of day-to-day HR work, and closer to 88 percent of purely administrative tasks like forms and routine transactions. Strategy work, culture building, and judgment calls on people decisions remain firmly human territory, and that split is unlikely to move much even as the tools get better.

What “Autonomous Workforce Orchestration” Actually Means

The phrase sounds abstract until you see it in practice. It simply means multiple agents, each built for a narrow job, working off shared data and shared goals instead of operating as isolated tools.

Think of a recruiting agent, an onboarding agent, and a compliance agent all reading from the same employee record. When a candidate accepts an offer, the recruiting agent’s job ends and it hands context, not just a status update, to the onboarding agent, which already knows the start date, the role, the manager, and the equipment needs. Nobody re-enters that information. Nothing gets lost between systems.

This only works if the underlying data is actually connected. ADP has pointed out that agents can only reason well when they can see across the HRIS, payroll, ATS, and ticketing systems at once. An agent boxed into a single platform behaves like a smart tool. An agent with access across the stack behaves like an orchestrator. The technology is rarely the bottleneck here. Messy, siloed data usually is.

Platforms like Sana, Moveworks, and ServiceNow have built their pitch around exactly this orchestration layer, connecting HR, IT, and finance systems so agents can complete a request end to end instead of stalling out at the edge of one tool.

The Human Role Doesn’t Disappear. It Moves.

Microsoft’s research on what it calls “Frontier Firms” describes organizations moving through three stages: people using AI assistants, then human-agent teams working side by side, and eventually human-led operations where agents run day-to-day execution under human direction. That last stage has produced a new kind of job title inside some companies: the “agent boss,” someone whose real work is managing a portfolio of AI agents the way a manager once managed a team of people.

That is not the same as HR disappearing. If anything, the roles that remain get more human, not less. When agents absorb the scheduling, the data entry, and the first-pass screening, HR professionals get their time back for the parts of the job that were always the hardest to automate: coaching a manager through a tough conversation, mediating a conflict, deciding how to handle a genuinely ambiguous case, and shaping the culture that no dashboard can capture.

Josh Bersin’s research on this shift makes a similar point. Companies that redesign the work itself around human-agent partnership, rather than just bolting AI onto existing processes, see the largest gains, sometimes several times the output of teams that never rethought how the work is structured in the first place.

The Part Nobody Should Skip: Governance

None of this works without guardrails, and the companies getting agentic AI right are the ones treating governance as part of the design, not an afterthought bolted on after something goes wrong.

A few things matter more than the rest:

Clear escalation rules. Scheduling an interview is low stakes. Deciding on a pay adjustment or a termination is not. The best agentic systems are built with explicit boundaries around which decisions an agent can finalize and which ones must land on a person’s desk before anything happens.

Audit trails. Every action an agent takes, and the reasoning behind it, needs to be logged and reviewable. This matters for compliance, and it matters just as much for building trust with employees who want to know a real person is accountable for decisions that affect their work life.

Data quality as a first step, not a side project. An agent is only as good as what it can see. Before scaling agents across the HR stack, the harder and less glamorous work is making sure the HRIS, ATS, payroll, and benefits systems can actually talk to each other.

Regulatory awareness. Laws around pay equity, hiring bias, and algorithmic decision-making are catching up to this technology fast. Explainability is likely to become a requirement rather than a nice-to-have, so building agents that can show their reasoning now will save a lot of retrofitting later.

Where to Start if You’re Behind

PwC’s own survey found that while nearly 8 in 10 executives say their companies are already adopting AI agents somewhere in the business, only about 4 in 10 have brought agents into HR specifically. That gap is an opportunity for anyone willing to move now rather than wait for the space to get crowded.

A sensible starting point looks like this:

• Pick one workflow with a clear, measurable pain point, usually recruiting screening or onboarding coordination, and pilot an agent there before attempting anything enterprise-wide.
• Fix the data connections between your core systems before adding more tools on top of a fragmented stack.
• Define escalation and approval rules before the agent goes live, not after the first edge case surfaces.
• Treat the rollout as iterative. Expect to adjust the agent’s rules as you see how it behaves against real cases, rather than expecting it to be right on day one.
• Keep people at the center of anything involving pay, termination, promotion, or other decisions with real consequences for someone’s livelihood.

The Bottom Line

Agentic AI is not another item on the HR tech shopping list. It is a different operating model, one where routine, cross-system work runs largely on its own and human attention shifts toward judgment, empathy, and the decisions that genuinely need a person behind them.

The organizations that treat this as a chance to redesign how HR work gets done, rather than just automating the same broken process faster, are the ones that will see the biggest gains. The technology is ready sooner than most HR teams expect. The real work now is getting the data, the governance, and the people ready to work alongside it.

Frequently Asked Questions

What is agentic AI in HR? Agentic AI in HR refers to AI systems that act autonomously across HR workflows. Rather than waiting for a person to ask a question, these agents monitor signals like a stalled hiring pipeline or a compliance change, decide on the right next step, and carry it out across connected systems like the HRIS, ATS, and payroll platform.

How is agentic AI different from a generative AI chatbot? A generative AI chatbot responds when prompted and stops there. An agentic system initiates action on its own, plans a sequence of steps, executes them across multiple tools, and only involves a human when a decision requires judgment or carries real consequences.

Will agentic AI replace HR jobs? Most research points to a shift in focus rather than a wholesale replacement. Agents are taking over administrative and repetitive tasks, while strategic work, culture building, coaching, and sensitive people decisions remain led by humans, often with more time to devote to them than before.

What should HR teams do first before adopting agentic AI? Start by connecting the data across core HR systems, since agents can only reason well with access to a full picture. From there, pilot agents on one well-defined workflow, set clear rules for what requires human approval, and build in audit trails from day one.

Is agentic AI in HR safe from a compliance standpoint? It can be, provided governance is built in from the start. That means explicit escalation rules for sensitive decisions, complete audit logs of agent actions and reasoning, and ongoing attention to evolving regulations around algorithmic decision-making in hiring, pay, and promotion.

AI Assistants Are Old News;Agentic AI Is Transforming HR was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

I started LeetCode again after a small break. I don’t know how many times I’ve restarted LeetCode.

This time, I decided to follow the NeetCode roadmap. It made learning LeetCode easier. It actually has structure and order. That made it easy to pick the next problem without thinking much.

I completed the following sections:

• Arrays & Hashing
• Two Pointers
• Sliding Window
• Stacks (recently completed)

After completing the sections, I looked at one of my accepted solutions and thought, “I know I solved this three days ago. Why can’t I explain why this line exists?”

Of course, I didn’t memorize the problems. I actually understood each one before moving on to the next problem.

So I decided to recollect everything from scratch. No hints.

I opened my notebook and started revising the sections I had completed.

Everything has an approach. I wanted one for revision too.

I wasn’t trying to invent new ideas. I just wanted to remember the old ones.

My approach was simple.

Just write.

Write everything.

• What were my initial thoughts?
• How did I solve the problem?
• How did I identify the logic?
• How did I eliminate the unnecessary work?
• How did I extract the optimized solution from the brute-force solution?

Write everything in simple English.

So I started writing every decision and every thought I had while solving that particular problem.

While solving, I only focused on getting the solution.

I just wrote the input and output, listed every approach I knew, and started solving.

I only cared about getting the problem accepted. My focus narrowed.

Once the problem was solved, my brain relaxed.

But during revision, I finally got to relax. I no longer had to search for an answer. Now I could ask why my reasoning worked.

That’s when I found something interesting. I wasn’t focused on getting to the solution quickly anymore. Instead, I became a reviewer and examined my own solution.

In this process, I repeatedly asked questions like:

• If that worked, why didn’t this?
• Why did this work?
• Why did I choose this data structure?
• Why did I make that decision?

While solving, every question was judged by one standard: “Will this get accepted?”

During revision, that pressure disappeared, and I finally started asking ‘why’ instead of ‘how’.

That created space for new ideas.

Voila.

I found ideas I hadn’t considered before.

I discovered new ways to solve the problem.

I understood the reasoning better and connected the dots.

That experience was incredible. I was in awe.

While revising, I remembered an essay I had read during my digital detox (which I eventually failed).

It was an essay by Paul Graham called Good Writing.

In Good Writing, he wrote:

This is only true of writing that’s used to develop ideas, though. It doesn’t apply when you have ideas in some other way and then write about them afterward.

It’s only when you’re writing to develop ideas that there’s such a close connection between the two senses of doing it well.

I remember thinking, “Is that really true?”

I thought, “Okay, let’s see.”

Then I moved on, like any other procrastinator.

I thought this kind of writing only helped people developing completely new ideas — essayists, philosophers, and researchers. Algorithms already felt finished to me. I thought writing was useful only when people were trying to discover something completely new.

I never imagined it would help while revising algorithms.

But during revision, I realized he was right.

This is what happened to me.

Yes, maybe you’ll find useless ideas.

A useless idea is still an idea.

Wrong ideas still teach you why the right idea is right.

You may not find the correct solution every time, but you’ll understand why one approach fails and another works. You’ll develop a much deeper understanding of the reasoning.

Sometimes, you even discover a better idea.

Either way, writing helps you walk away with something.

It made me wonder where else this way of writing could be useful.

Here are two questions I never asked while solving the problems but naturally asked while writing about them.

Product of Array Except Self

While solving it, I used prefix and suffix arrays. I calculated the suffix array on the go.

While writing about it, one question came to mind:

Why can’t I calculate the prefix on the go?

It turned out I could.

Longest Repeating Character Replacement

While solving it, I needed to calculate the number of replacements required. I calculated it using windowLength - maxFreq.

Here, maxFreq is the highest frequency of any character in the current window.

Then I wondered:

Why can’t I calculate minFreq instead?

minFreq would simply be the sum of all frequencies except the maximum one.

The answer was yes — but with a trade-off.

The idea worked, but it required another traversal, making it slower than the standard windowLength — maxFreq calculation, which is O(1).

let maxFreq = 0;

for (let freq of map.values()) {
    maxFreq = Math.max(maxFreq, freq);
}
let minFreq = 0;
let skippedMax = false;
for (let freq of map.values()) {
    if (!skippedMax && freq === maxFreq) {
        skippedMax = true;
        continue;
    }
    minFreq += freq;
}
if (minFreq <= k) {
    // valid window
}

Now compare that with the standard solution.

My approach

Find max       -> O(26)
Find minFreq   -> O(26)

Standard approach

Find max      ->  O(26)
windowLength - maxFreq  -> O(1)

The new idea wasn’t more optimal, but it made me understand why the standard solution was.

My notebook pages:

These pages hold more than solutions. They hold questions, failed ideas, better ideas, and conversations with my past self. Somewhere along the way, my notebook stopped being a revision notebook and became a place where I learned how to think.

I always thought revision was about remembering what I had already learned.

Instead, it became a conversation with my past self.

Sometimes I discovered better ideas.

Sometimes I simply understood why my original idea was already the right one.

Either way, I always walked away with a deeper understanding than when I started writing.

Thanks for reading.

Writing My LeetCode Solutions Changed How I Think was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the greatest resources for me when starting out was attending events or conferences hosted by senior engineers.

I used to and still watch many such conferences available on YouTube or attend them in person, as they helped me gain deeper insights into how things actually work. Be it Cloud, DevOps, Golang, or even Linux internals, these tech talks have always fascinated me.

While watching such videos, I would always think that someday I would also be giving a talk in front of many people and sharing my knowledge with them.

And honestly, that day wasn’t very far away. At the start of 2026 itself, in March, I got the opportunity to give a technical talk at Opstree Solutions.

The session was titled “Building CI/CD Pipelines for Infrastructure: From Automation to Testing.”

It focused on my ideas and perspectives based on the book Infrastructure as Code Dynamic Systems for the Cloud Age written by Kief Morris.

That book introduced some really interesting ways of looking at Infrastructure as Code. The point that intrigued me the most was how to test and implement a CI/CD pipeline for IaC, especially for provisioning code.

Although there were times while preparing for this talk when I couldn’t fully understand a few concepts, I now think I should have consulted a senior. But anyway, I searched online, and Reddit turned out to be a huge help. I also couldn’t complete the demo, which, in hindsight, should have been my highest priority.

Anyway, here are some lessons I learned from my experience and from watching the other speakers at several events:

Always introduce yourself

Some people really struggle with this, and honestly, so do I. I get confused about what to say about myself. Well, that mainly depends on how well you know yourself. But when you’re starting out, you can simply say something like:

“Hey everyone, I’m Rajeshwari. I’m a freelance Cloud Engineer, and I love brewing coffee.” (Or not, if you actually don’t. 😄).

And that’s it. You don’t have to make it fancy.

Keep the audience engaged

This is probably the most important aspect of giving a talk. If you just keep talking and describing your slides, it starts feeling like a boring office meeting.

Instead, at regular intervals, ask the audience if they have any questions. Or even better, while introducing a topic, ask if someone already knows the answer before explaining it yourself. It naturally makes people more involved.

I wasn’t able to keep my audience as engaged as I wanted, but honestly, Sandeep sir made the session much more interactive by asking me thoughtful questions throughout the talk. It also helped me deepen my own understanding of the topic.

Always prepare the demo!!

One drawback of my talk was that I couldn’t prepare the demo completely. As I mentioned earlier, there were a few concepts that I couldn’t fully grasp while preparing, which resulted in an incomplete demo, and I couldn’t present the code.

Thankfully, I had created a pipeline flow diagram as a backup and presented that instead.

Do not overprepare

Actually, I’d say prepare at all! I didn’t prepare the night before the talk or even 15 minutes before it. You already know the topic, and you’ve created the presentation, so why memorize everything? You can prepare a few key points that you want to cover, but don’t lock yourself into a script.

Just keep the conversation flowing while you’re on stage. I stayed calm and didn’t think much about the session beforehand. I was simply excited to attend the event itself. Trust me, it relieves a lot of pressure.

Write small pointers, not big sentences

The point of a talk isn’t to show off your PowerPoint; it’s to show your understanding of the topic. For me, the best feeling is talking naturally, with ideas coming to my mind at that very moment instead of reading what’s written on the slides and explaining it again.

Even I couldn’t do this perfectly. Some of my slides were filled with too much text, and that definitely shouldn’t have happened.

So these were some of the lessons and experiences from that day.

The opportunity to give tech talks is one of the best things this field has given me. ❤️

Looking forward to many more such experiences!

And all the best for your first session!! 🙌🌟

Originally published at https://www.linkedin.com.

All about my very first technical talk was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most teams build AI features as a one-way door. Here’s what it looks like to build one you can walk back through.

(Not a Medium paid member…no worries, read for free here)

You know the AI feature is done “right” when someone asks the obvious question and the room goes quiet.

What happens if we turn it off? (Not many have really planned for that)

Concepts like “backward compatibility” or “two-way door decision” have kinda lost their charm in the so-called “AI-first race”.

And even if teams treat “add AI” as a two-way door (reversible at any time) and build it that way, it's usually only in name.

In practice:

Once old system’s gone, it’s a one-way door wearing a two-way door’s reputation.

The Assumption Baked Into Most AI Features

Behind every AI feature you can see, there used to be a boring system that just worked. Rules. If-this-then-that. Not exciting, but solid.

But as AI entered the picture, instead of standing alongside the old system, it stood atop it and pushed it out of the way.

And the boring (non-AI) version didn’t get kept. It got deleted.

So now the model is the system. And the day it hallucinates, or the API times out, or someone’s config drifts, there’s nothing behind it to catch the fall. Just the user, staring at whatever the model handed them.

What Building It the Other Way Looks Like

The fix isn’t complicated. It’s just unfashionable because it means shipping the boring version first on purpose and treating it as permanent infrastructure, not a rough draft you throw away once the AI works.

Here’s the shape of it, using a plain example: a system that reviews a piece of text and flags issues before it ships (could be a support macro, a config file, a product description, doesn’t matter).

Step 1: Build the deterministic core (this is the system, not a placeholder for the system).

# core.py

def deterministic_review(text: str) -> dict:
    """
    Rule-based review. No AI. No external calls.
    This is the source of truth. Everything else is optional on top of it.
    """

issues = []

if len(text) < 20:
        issues.append("Content too short to be useful.")

if text.strip().endswith((".", "!", "?")) is False:
        issues.append("Missing terminal punctuation.")
        
banned_terms = ["TBD", "TODO", "placeholder"]
for term in banned_terms:
        
if term.lower() in text.lower():
        issues.append(f"Contains unresolved placeholder: '{term}'")

return {
        "source": "deterministic",
        "issues": issues,
        "passed": len(issues) == 0,
    }

Nothing clever here. That’s the point. This function will give you the same answer every time, forever, regardless of what any model provider does to their API next quarter. It’s not exciting. It’s load-bearing.

Step 2: The AI layer sits beside it (and not inside it).

# enhancer.py

import os
from openai import OpenAI

client = OpenAI()

def ai_review(text: str) -> dict:
    """
    AI-assisted review. Adds judgment the deterministic layer can't.
    Never the only line of defense. Never load-bearing on its own.
    """
    prompt = f"""
    Review the following content for clarity, tone, and ambiguity.
    Do not invent facts. Do not rewrite the content.
    Return a short list of specific concerns, or "No concerns" if none.

    Content:{text}
    """
    
response = client.chat.completions.create
    (
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": prompt}],
    temperature=0,
    )

return 
    {
    "source": "ai",
    "notes": response.choices[0].message.content.strip(),
    }

Notice what this function does not do. It doesn’t decide pass/fail. It doesn’t touch the original text. It doesn’t get called unless something upstream explicitly asks for it. It adds a second opinion. It never replaces the first one.

Step 3: The toggle (the focus point of this article).

# pipeline.py

from core import deterministic_review
from enhancer import ai_review

def review(text: str, use_ai: bool = None) -> dict:
    """
    The public entry point. Deterministic result is always computed
    and always returned. AI is additive, and fails safe.
    """
    use_ai = use_ai if use_ai is not None else os.getenv("USE_AI", "false").lower() == "true"

    result = deterministic_review(text)

    if not use_ai:
        return result

    try:
        ai_notes = ai_review(text)
        result["ai_notes"] = ai_notes["notes"]
    
    except Exception as e:
        # AI failed. The deterministic result is already computed and valid.
        # We log it, we don't crash, and we don't silently pretend AI ran.
        result["ai_notes"] = None
        result["ai_error"] = f"AI layer unavailable: {str(e)}"

    return result

Three things are true about this function that weren’t true about the “AI-as-the-feature” version most teams ship:

• The deterministic result is computed unconditionally, before AI is even considered. It’s not a fallback path bolted on after the fact. It’s the actual return value, every time, and AI either adds to it or doesn’t.
• The toggle is a real toggle. USE_AI=false doesn't mean "the AI feature is disabled and something is missing." It means the system runs exactly as it did before AI existed. Nothing degraded. Nothing broken. Just the version that was always there.
• Failure is visible, not silent. If the AI layer breaks, the response says so, explicitly, rather than quietly returning a worse answer and hoping nobody notices. ai_error is a field a caller can check. It's not swallowed by a bare except: pass.

Why the Off Switch Has to Exist Before You Need It

Now here’s the thing about off switches important to remember.

You can’t add one retroactively, not really, not once a system has been live long enough that people have started trusting the AI-touched version as the version.

By the time something goes wrong, an “off switch” you build under pressure is really a panic button wired to a system that was never designed to run without the thing you’re now trying to remove. It’ll work, technically. It’ll also break three things you didn’t know depended on the AI layer being there.

The toggle in the code above costs almost nothing to build, if you build it on day one. It costs a full re-architecture to build after the fact, once “the AI version” has quietly become “the only version.”

So build the boring layer first. Keep it running underneath, permanently, not as a bootstrapping step you delete once the AI works. Let AI sit on top, opt-in, fail-safe, and honest about its own failures.

To conclude, I would say:

The real measure of whether a team understands AI governance isn’t whether they added guardrails.

It’s whether they could turn the AI off tomorrow, mid-incident, and still have a working system underneath.

Most teams, if they’re honest, would find out the hard way that they can’t.

Better to find that out in a design review than in production.

Thanks for reading this article; don’t forget to clap and follow ❤️

You can send me an invite @ LinkedIn or Substack 😎

Looking forward to connecting with you 🤝

You may also like to read:

• When RAG Fails, Look Beyond the Vector Database
• You Can’t Scale Content Without Scaling Its System!
• Your AI Agent Is Only as Confident as Your Least Confident Page

Trust Is a Toggle, Not a Feature: Why AI Should be Shipped With an Off Switch was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Break the silence around compensation

July 21, 2026, was Black Women’s Equal Pay Day here in the U.S. It’s a symbolic date that marks how far a Black woman must work into the current year to make the same amount that a white, non-Hispanic man earned last year.

Another way to look at it? Imagine finding out you’ve been earning just 65 cents for every dollar paid to a coworker. That’s the current wage gap for Black women working full-time, year-round in the U.S.

And there are more equal pay day milestones coming up, each revealing deep disparities:

• Moms’ Equal Pay Day — August 6
• Native Hawaiian and Pacific Islander Women’s Equal Pay Day — September 15
• Latina Equal Pay Day — October 8
• Disabled Women’s Equal Pay Day — October 20
• Native Women’s Equal Pay Day — November 19

While I hope your organization conducts regular pay equity reviews and addresses any inequities, there’s also something we can do on a personal level: Discuss our compensation.

It’s uncomfortable territory for many of us, but when we tell others what we make, we provide them with valuable data points. And data is a helpful tool in any negotiation process.

Share this action on Instagram, LinkedIn, or YouTube.

2. Don’t expect someone to use a personal credit card

Should employees and job candidates have to use their own credit card for business travel and other expenses?

Paolo Gaudiano and Cynthia Overton argue in their new book Meritocracy that this common workplace practice is one of many that quietly undermine merit.

They explain that structural enablers and organizational biases prevent meritocracy all around us. For example:

• The enabler: The organization requires individuals to pay business travel costs upfront and request a reimbursement later.
• The bias: This creates bias among employees at different socioeconomic positions. Not everyone can float hundreds — or thousands — of dollars in company expenses. Some people don’t have a credit card. Others have low credit limits or can’t afford to carry the balance while waiting weeks for reimbursement.
• The solution: Hire a company travel agent, provide corporate credit cards paid by accounting, give cash advances.

If someone needs to travel or make purchases for work, don’t assume they can “just put it on their credit card.” Instead, provide another option.

For example, use virtual credit cards (VCCs) or temporary prepaid corporate cards, available from many financial institutions. They allow your business to instantly issue temporary 16-digit card numbers for specific trips, set firm spending limits, and restrict charges to travel categories such as flights and hotels.

3. Help people notice harmful stereotypes

“It’s taking longer because the decision maker is older and more cautious.”

I heard a leader make this comment during a recent virtual meeting.

My first instinct was to let it go. I had another meeting starting soon. This leader was someone I respected. He was thoughtful and empathetic. Maybe it wasn’t worth bringing up.

But I try to practice what I preach.

So, as the call was wrapping up, I asked the leader if he could stay on the line for a few more minutes because I had something I wanted to share with him.

After everyone else left, I said, “I hope you’re open to some feedback” and then summarized what I had heard him say. I pointed out that he had reinforced a negative stereotype about older people, and that while I didn’t think he meant any harm, he sent a subtle message to others on that call that it’s okay to assume older folks are going to be slower and more cautious with decision-making or other aspects of their job.

I added, “You could simply have said the decision was taking longer than expected, without attributing it to their age.”

He nodded in agreement and sincerely thanked me for the feedback.

It reminded me that these conversations don’t have to be confrontational. A respectful conversation after the meeting can be enough to help someone notice a stereotype they hadn’t realized they were reinforcing.

I hope you’ll do the same the next time you witness one.

4. Call out disgusting jokes

Last week, the US Defense Secretary Pete Hegseth mandated testing testosterone levels for service members over 30 and recommended hormone therapy if needed. Afterward, Fox News host Jesse Watters made an awful joke on air about it. He chuckled, saying,

“Women on base: you better be careful. Port calls, women in Asia: you better be careful. Because these guys are going to be wild animals, and you better watch out.”

Sexual violence is not something to joke about.

And as I shared in a previous newsletter, research shows that when someone tells a denigrating joke, it signals that behavior is acceptable. People who might normally conceal their feelings feel freer to express them.

As better allies, let’s speak up. For example, “We don’t joke about rape here.”

5. Community spotlight: Pay attention to the people around you

A subscriber from Berlin wrote to tell me about something she’s been noticing on public transportation: there’s a general lack of awareness of people with disabilities and access needs.

Here are some examples she regularly sees:

• A blind person navigating roads, using the markings for blind people, which are fully occupied by people walking with rolling suitcases.
• A parent juggling a stroller, a child, and shopping bags, with no one offering their seat or making space for the stroller.
• A wheelchair user trying to navigate a crowded train, weaving around bags and feet that never move because no one looks up.

She urges all of us to, “Look up and be aware of your surroundings so you’re able to offer help in situations where it’s needed.”

Most people are perfectly capable of managing on their own. But knowing someone noticed and cared enough to make space or ask how they might help can make all the difference.

🙏

If you’ve taken a step towards being a better ally, please reply to this email and tell me about it. And mention if I can quote you by name or credit you anonymously in an upcoming newsletter.

That’s all for this week. I’m glad you’re on this journey with me,

Karen Catlin (she/her), Author of the Better Allies® book series

Copyright © 2026 Karen Catlin. All rights reserved.

Together, we can make a difference with the Better Allies® approach.

• Say thanks to Karen and buy her a coffee ☕ (Need a receipt for educational reimbursement? Reply to this email, and we’ll take care of it.)
• Sponsor an edition of this newsletter
• Follow @BetterAllies on Instagram, Medium, or YouTube. Or follow Karen Catlin on LinkedIn
• Read the Better Allies books
• Tell someone about these resources

Break the Silence Around Compensation, and Other Actions for Allies was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.