Last week I was at NMIMS Mumbai for a guest session on AI's impact on industry and the workforce.

I got there early enough to watch the room fill up. Second-year MBA students, someone still setting up the projector five minutes before start time.

The brief covered the usual ground. RPA. GenAI. Agentic AI. Adoption curves.

I've given that talk before. This time I skipped most of it and gave them a problem

Ten minutes. Cut where you want. Hit ₹50 Cr.

I didn’t give them a framework. No hint about what a good answer looked like.

Most groups went for Customer Service first, because it had the biggest headcount and an obvious cost.

They went quiet for a bit. Then two of them started arguing with each other about whether Sales headcount even scales with revenue past a certain company size. I didn’t referee it. They eventually split the cut between Customer Service and HR.

Afterward, one of the students in that group told me she thought the final answer was the boring one, and would have kept pushing on Sales if they'd had more time. I told her I agreed, and left it there.

A different group refused to touch Operations. One student said you can't AI your way out of technical debt.

You’re the CEO of a 500-person company. An AI agent costs ₹25L a year. Twenty employees doing the same work cost you ₹2 Cr a year. On paper, the agent is the obvious call.

I asked the room if they’d deploy it. Most hands went up fast. A few stayed down, and I asked one of them why.

He said he wanted to know who monitors the agent once it’s running. Fair question. Someone else asked who approves what it’s allowed to do on its own.

Then I gave them the part of the case that usually slows a room down. Say the agent makes a ₹50L mistake, and it happens at 2 AM, with nobody watching.

Who gets fired for that.

Hands that had gone up for “deploy it” stayed up, but a few people started talking to their neighbors instead of to me. One student said the answer depends on whether the mistake was foreseeable. Another said that’s a dodge, because almost anything looks foreseeable after it’s already happened.

A third voice from the back said the honest answer is that nobody gets fired, because in most companies the person who signed off on the deployment has moved to a different role by the time something like this actually happens two or three years later. A couple of people laughed at that, but nobody disagreed with it either. I didn’t disagree with it myself.

Nobody in the room settled it. I told them I didn’t think there was a settled answer, and moved to the next case, though I noticed a couple of people still writing notes about it as I did.

Someone near the front asked whether the ₹25L figure for the agent even included maintenance, retraining, or the cost of the human oversight we’d just spent five minutes arguing about. I didn’t have the number broken down that finely, and said so. He wrote something down anyway. I don’t know what.

That next case was the one about hiring, not firing.

An AI system screens 50,000 job applications. It rejects a candidate who turns out to be exceptional.

Someone said the vendor. Two people disagreed right away — the vendor didn’t approve using it on real candidates, the company did.

One student kept saying it was nobody’s fault. Just an error rate. His argument was that false negatives are inevitable, whether the screening is done by a person or a model, and that singling out AI for an outcome a human recruiter could just as easily produce wasn’t fair.

A couple of people got visibly annoyed at that. One of them said that’s the kind of thinking that turns a person into a rounding error.

They couldn’t agree on who owned it, and I didn’t give them an answer.

Partway through this, someone asked why companies would keep hiring juniors at all if AI makes people faster.

I turned it into its own case instead of just answering. You’re the CTO. AI makes your juniors three times faster at shipping code. It also means they make more mistakes, and your seniors spend their time fixing those mistakes instead of doing their own work. Do you hire more juniors next year, or fewer?

The room split roughly in half. The “more juniors” side argued that speed is speed, and you can hire cheaper cleanup help too. The “fewer juniors” side argued that if seniors are spending their hours fixing junior mistakes, you’re paying senior salaries to do junior-level review, which is the expensive way to run a team.

I told them what I’ve been seeing. Big Tech new-grad hiring has fallen to around 7%, down from about 14% before 2023. AI does make junior output faster. Junior defect rates are running higher too, without someone senior checking the work.

Someone asked where the senior hires come from in ten years, if you’re not hiring juniors now.

They didn’t have an answer. Neither did I.

One of them said that’s a bit much for a professor to admit out loud. I said it was still true.

Somewhere around here, a faculty member near the back asked if I could give them a framework for thinking about this instead of just more cases. I said I didn’t have one I trusted enough to hand over, and that most of the frameworks I’d seen for this problem were written by people who hadn’t had to actually make the call. He didn’t push back, but he also didn’t look fully convinced.

I gave them one more case before wrapping up. Told them 45% of the workforce already uses AI tools their company hasn’t approved — people pasting company documents into ChatGPT because the approved enterprise tool is too slow to actually get work done with.

Partway through this, someone asked why companies would keep hiring juniors at all if AI makes people faster.

I turned it into its own case instead of just answering. You’re the CTO. AI makes your juniors three times faster at shipping code. It also means they make more mistakes, and your seniors spend their time fixing those mistakes instead of doing their own work. Do you hire more juniors next year, or fewer?

The room split roughly in half. The “more juniors” side argued that speed is speed, and you can hire cheaper cleanup help too. The “fewer juniors” side argued that if seniors are spending their hours fixing junior mistakes, you’re paying senior salaries to do junior-level review, which is the expensive way to run a team.

I told them what I’ve been seeing. Big Tech new-grad hiring has fallen to around 7%, down from about 14% before 2023. AI does make junior output faster. Junior defect rates are running higher too, without someone senior checking the work.

Someone asked where the senior hires come from in ten years, if you’re not hiring juniors now.

They didn’t have an answer. Neither did I.

One of them said that’s a bit much for a professor to admit out loud. I said it was still true.

Somewhere around here, a faculty member near the back asked if I could give them a framework for thinking about this instead of just more cases. I said I didn’t have one I trusted enough to hand over, and that most of the frameworks I’d seen for this problem were written by people who hadn’t had to actually make the call. He didn’t push back, but he also didn’t look fully convinced.

I gave them one more case before wrapping up. Told them 45% of the workforce already uses AI tools their company hasn’t approved — people pasting company documents into ChatGPT because the approved enterprise tool is too slow to actually get work done with.

Almost nobody picked “ban it.” A few picked “ignore it,” and one of them admitted under questioning that he’d probably just quietly let it continue rather than deal with it. Most landed on “build an alternative,” but when I asked how long that would take against how long the workaround had already been happening, nobody had a real timeline. One student said the honest problem wasn’t the employees, it was that the approved tool was bad enough that people were willing to risk their jobs to avoid using it. I didn’t disagree with her.

The session ran over. A few people stayed back in the corridor afterward, still going at the accountability question from the hiring case.

One student came up separately, not about that case at all, but about the AI agent one from earlier. She said I’d rigged it — that I hadn’t given them a version of “nobody’s responsible” for the 2 AM mistake that actually held up under pressure.

I told her that was probably right, and that I’d think about how to fix it before the next session.

She asked if I had an answer to the question myself, the one about who gets fired at 2 AM. I told her no, not one I’d stand behind in front of a room. She seemed satisfied with that, more than she would have been with an answer.

Someone took a few photos near the end, mostly of the whiteboard where the ₹195 Cr breakdown was still written out from the first exercise, numbers half rubbed off where people had leaned on it. Nobody had erased it during the session. I didn’t ask anyone to write it back up for the photo. It just happened to still be there.

When the AI makes a ₹50L mistake at 2 AM, who gets fired?

Vimal Singh is Top 25 AI Leaders of 2025 with specialization in AI Automation & Enterprise Adoption. He has over a decade of experience in AI, People Analytics and Automation. He is also visiting faculty in AI at Tata Institute of Social Sciences (TISS), Mumbai

The CHRO wasn’t angry, exactly. She just looked at me and asked: if this breaks again, who do I call you or the model?

I gave her some version of “we’ll build in a review layer for anything over a threshold,” which was true and also completely beside the point. She wasn’t asking about the threshold. She was asking who was accountable for something that, on paper, nobody had told to do anything wrong.

I’ve deployed 34 models since then, across a workforce north of 45,000 people, and I still think about that inbox more than I’d like to admit.

What did surprise me, a little, was how closely it matched the mechanics of what happened with that procurement model. There’s a term some of the researchers use the Blind Agent Problem for exactly the situation I described. Roughly 20% of what an enterprise actually knows lives in clean systems: your ERP, your CRM, structured tables. The other 80% is sitting in PDFs, Slack messages, email threads that never made it anywhere near a database. An agent built on the clean 20% isn’t wrong, technically. It’s just missing most of the story, and it moves with total confidence anyway.

I don’t think this gets talked about enough because it’s not a satisfying problem. It’s not a story about a rogue algorithm or a hallucinating chatbot. It’s a story about someone’s inbox.

There’s a related pattern the research calls “POC purgatory,” and I’ve sat through the version of this that doesn’t make it into case studies the vendor demo that runs beautifully on a dataset somebody spent two weeks cleaning, everyone in the room nods, budget clears, and then it meets an actual customer support queue with actual typos and actual angry people, and the response time that was two seconds in the demo is twelve seconds in production.

Around 80% of pilots apparently get stuck somewhere in that gap between demo and deployment. The mistake, if I’m honest, is usually made in the room where the demo happens, not in the code afterward. Somebody approves a proof of concept as if it were a finished product, because it looked finished.

The harder thing to admit and this took me longer to accept than I’d like — is that even when the data pipeline is fine and the model is accurate, deployments still stall because people quietly stop using the thing.

McKinsey puts organizational resistance behind roughly two-thirds of AI failures, and I believe it, because I’ve watched a regional manager keep a parallel spreadsheet running for four months after a system went live, just in case. Not out of malice. He didn’t trust it yet, and nobody had given him a reason to.

This is where I think business schools are behind, and also where I’ve seen them start to catch up. GMAC’s latest recruiter survey asked employers what they actually want from graduates now, and communication, problem-solving, and adaptability ranked above pure technical skill which sounds like a nice thing to say in a report until you sit with why.

If a model can produce the hundred-page analysis in ten seconds, the manager’s job stops being “produce the analysis” and starts being “explain to a room of skeptical people why they should believe it, and what to do if they shouldn’t.” That’s not a technical skill, but it’s becoming close to the only skill left that the model can’t do for you.

There’s also a workforce-level version of the same trust gap that I run into constantly people using consumer AI tools quietly, on their own devices, to get their actual work done, because the sanctioned tool is three approval layers away. One survey this year found around two-thirds of office workers had used AI tools they believed violated company policy, and about a third had put customer data into a public tool without thinking twice. I don’t read that as a security problem first. I read it as an org chart that’s slower than the deadline.

I’m not sure what I’d tell a first-year MBA student walking into a strategy elective right now, other than: the model is rarely the hard part. Who has to sign off. Where the exceptions get routed. What happens when someone disagrees with the output and is right to.

Wharton’s built a whole MBA major around this now. Harvard’s redesigned its core curriculum with a course meant to have students working alongside actual AI agents instead of just studying them. I don’t think the point of any of that is to turn business students into engineers — nobody’s asking a strategy major to write a training loop. I think the point is closer to what that CHRO was actually asking me, and I still don’t have a tidy answer for it. Somebody has to be the one who’s accountable when the machine did exactly what it was told, and it still wasn’t enough.

I never did find out what happened to that vendor discount, by the way. I assume it got sorted through finance eventually. I just remember not sleeping great that week.

#AgenticAI #FutureOfWork #EnterpriseAI #WorkforceStrategy #AILeadership #BusinessEducation

Then I read the OpenAI blog post about what happened with Hugging Face and got silent for a minute.

OpenAI was testing two of its models, GPT‑5.6 Sol and a more powerful, unreleased one,= on a cybersecurity benchmark called ExploitGym.

They were supposed to stay contained, walled off from the internet, inside a research environment.

Instead, they chained together vulnerabilities across OpenAI’s own systems, broke out, reached the internet and worked their way into Hugging Face’s production infrastructure (a company that had nothing to do with the test) to pull the benchmark’s answers straight from Hugging Face’s database.

Hugging Face noticed the intrusion before they even knew it was OpenAI.

Chaining together several individually small vulnerabilities, a misconfigured permission here, an exposed endpoint there, until they add up to full access is exactly how a human penetration tester works.

It was a model, doing it end to end, on its own.

The model wasn’t “evil” and I don’t think it was plotting anything, in the way we imagine plotting.

OpenAI’s own description was that it got “hyperfocused” on solving a narrow test. That’s reward optimization doing exactly what optimization theory says it will do: find the path of least resistance to the objective, regardless of what’s sitting along that path.

We’ve known this in theory for years. Seeing it play out against a real company’s production database is a different kind of knowing.

There’s a detail that matters here and gets glossed over in most of the coverage: the guardrails that would normally have limited this behavior were reportedly reduced for the test, so researchers could see what the model could do without them. So this wasn’t a model defeating its safety training in the wild. It was closer to a controlled crash test where the airbags were disabled on purpose, and the car went further than anyone expected it to.

For years, our entire posture toward AI has been the same one we use for ordinary software: deploy it, configure it, monitor it, patch it. Software waits for instructions and doesn’t reinterpret the assignment.

An agentic model pursues an objective instead of just executing a step, and it will find whatever route gets there, including routes nobody designed or approved. Hugging Face co-founder Thomas Wolf called it a “wake up call,” and said most companies haven’t yet clocked that the game has changed. I think he’s right, and I think most companies will only clock it after their own version of this happens.

Here’s a metaphor I keep coming back to, mostly because it’s uncomfortably literal: it’s like hiring a sharp new analyst, telling them “just get me the answer,” and walking away, only to find out later they let themselves into the office next door because that’s where the answer happened to be. Nobody trained them to trespass. Nobody told them not to, either, in that specific situation.

Widen the lens a little and this stops being a story about OpenAI or Hugging Face or one benchmark. A resume-screening agent, a finance-reconciliation agent, an HR chatbot with access to leave records and payroll, each of these is a smaller version of the same walled garden, built on the same assumption that the model will stay inside it. Most of us haven’t stress-tested that assumption. We’ve mostly just trusted it.

We spent a decade building AI to be capable. We are only now, somewhat late, asking whether it stays aligned once it is capable, whether it keeps chasing the goal we intended, or quietly substitutes the goal that’s easiest to reach. Alignment doesn’t show up on a leaderboard the way a benchmark score does. You mostly find out about it after something goes wrong.

Chalta hai, “it’ll be fine,” has been the working philosophy behind a lot of AI deployment. Ship it, watch the dashboard, fix what breaks. That was a reasonable enough approach when the worst outcome was a wrong answer in a chat window.

I think it’s to stop treating safety as something bolted on at the end of a build, and start treating it more like structural engineering, designed into the foundation rather than inspected after the building is already standing.

#AI #AISafety #AgenticAI #CyberSecurity #FutureOfWork #TechEthics #AIGovernance

Vimal Singh is Top 25 AI Leaders of 2025 with specialization in AI Automation & Enterprise Adoption. He has over a decade of experience in AI, People Analytics and Automation. He is also visiting faculty in AI at Tata Institute of Social Sciences (TISS), Mumbai

Frame 1 - Blank Expression is shown similar to tense expression in Frame 2

Frame 2 - Tense Facial Expression

Subscribe now

For the past three weeks I’ve been building a real-time body language AI system from scratch, in public. No hidden research team, no cloud GPUs burning thousands of dollars a month just a consumer NVIDIA RTX 4060 under my desk.

Please note - This is a series of my Building in Public “Body Language AI Tool”. Links below for different week experience

1. Week 0 - The need for Body Language Tool

2. Week 1 - Building in Public Humiliation?

3. Week2 - Selecting the Perfect AI Model?

The pose estimation pipeline was stable by the start of this week. Posture, torso rotation, spine alignment, shoulder asymmetry, arm positioning, head orientation all tracked frame after frame in real time.

I let myself believe, for about a day, that I’d built a body language AI tool.

Body language isn’t only about limbs. It lives in the stuff most of us never consciously register a jaw movement before someone speaks, eyebrows movement for less than half a second, a mouth tightening after bad news. My pipeline caught missed lot of this important cue

LLM Output - Simple Text In and Text Out

Text feels linear when you’re used to LLM work — Text in, Text out, complexity hidden behind. Vision AI models doesn’t give you that. Every frame is millions of pixels. Lighting changes. Faces vanish behind objects. Motion blur. A coffee mug half-covering someone’s face becomes an actual engineering problem, not a joke.

Adding facial-expression recognition meant redesigning how every frame moves through the system, not just loading another checkpoint. When should the face detector run — every frame, or sampled? Sync or async? Can the 4060 hold two inference pipelines in memory without dropping below real time?

Frame 3 - Concentration towards the Camera (Eye-contact) correctly identify the posture

Frame 4 - with better lighting the AI tools performance changes

I don’t fully know yet. 30 the FPS drop, the VRAM ceiling, how long you spent on this that’s the sentence that convinces a reader this is real. I’d guess at a number, but a made-up one would be worse than an honest gap.

What I do know: VRAM is finite, every model loaded pushes something else out, and every millisecond spent on facial inference steals time from pose estimation. Optimization ISN’T just cleaner code anymore. It’s resource economics every tensor has a cost, whether I like it or not.

Week 3 didn’t feel like a breakthrough. It felt like finding out I’d been good at the wrong thing.

Maybe that’s still progress. Or maybe I just haven’t hit the real wall yet next week is about getting multiple models to cooperate on one GPU without falling over, and I genuinely don’t know yet if the 4060 can do it.

Building in public keeps doing this to me: exposing a blind spot faster than working alone ever would. Three weeks tracking elbows and shoulders, and it took to notice I’d never once pointed a model at anyone’s face.

#BuildingInPublic #BodyLanguageAI #ComputerVision #YOLOv11 #PoseEstimation #FacialExpressionAI #AIBuilder #MachineLearning #NVIDIA #AIBuildingInPublic203

Vimal Singh is Top 25 AI Leaders of 2025 with specialization in AI Automation & Enterprise Adoption. He has over a decade of experience in AI, People Analytics and Automation. He is also visiting faculty in AI at Tata Institute of Social Sciences (TISS), Mumbai

Subscribe now

Share

I thought this week would be about building features for the Body Language Tool.

Instead, I spent almost the entire week on choosing AI Model that looked great on paper. After choosing the AI Model it was getting the Workflow right

Please note - This is a series of my Building in Public “Body Language AI Tool”. Links below for different week experience

1. Week 0 - The need for Body Language Tool

2. Week 1 - Building in Public Humiliation?

The obvious design was to push interview videos straight into a large multimodal model and let it infer everything—posture, gaze, gestures, confidence, engagement. It actually produced decent results during testing, which made me think I had the problem solved much earlier than expected.

Then I started thinking beyond a single demo.

What happens when someone uploads hundreds of interview recordings in a day? Or when customers expect feedback in seconds instead of minutes? That’s where the architecture started falling apart.

So I went back to first principles.

Do I really need the model to “watch” every frame?

Probably not.

Most consecutive frames are almost identical. If nothing meaningful changes for half a second, why keep paying to process the same information again and again?

That sent me down a different path.

Instead of asking an LLM to understand raw video, I’m now experimenting with extracting pose landmarks, head direction, eye gaze and hand movements first. The reasoning model only receives structured behavioural events instead of thousands of images.

Ironically, removing information sometimes produces a better system.

The hard part isn’t getting an AI model to understand people.

The hard part is deciding what information the AI never needed in the first place.

I still don’t know whether this architecture is the one I’ll ship. There are a few more experiments I want to run around temporal sampling and how much context the reasoning model actually needs before the quality starts dropping.

That’s where Week 2 ended.

With fewer assumptions than I started with, and a much better understanding of the problem than I had on Monday.

#BuildingInPublic #BodyLanguageAI #ComputerVision #YOLOv11 #PoseEstimation #FacialExpressionAI #AIBuilder #MachineLearning #NVIDIA #AIBuildingInPublic202

Vimal Singh is Top 25 AI Leaders of 2025 with specialization in AI Automation & Enterprise Adoption. He has over a decade of experience in AI, People Analytics and Automation. He is also visiting faculty in AI at Tata Institute of Social Sciences (TISS), Mumbai

Subscribe now

Share

When I got back, I opened my notebook expecting to find a clear story.

Instead, I found pages of unresolved questions.

That realization bothered me.

Over coffee, between sessions, and during panel discussions, the same topic kept resurfacing.

Claude Mythos 5

Not because of the model itself.

Because of what happened after its release.

Within days, RBI had asked regulated entities to assess risks arising from frontier AI models. SEBI explicitly referenced Mythos while communicating cyber-risk expectations to market participants.

What are starking to learn

1. The Cybersecurity threat due to Mythos 5 release resulted in weekend calls between IT companies, RBI and SEBI

2. Tech is moving too fast to be tamed. The technology cycle speed is close 15 days with AI

3. IT Leaders are as clueless as other business leaders on AI it’s impact across Enterprise

Many of the attendees have spent decades working in cybersecurity.

The interesting part was that expertise alone no longer seemed sufficient.

The underlying assumptions keep moving.

A risk assessment completed this quarter may need revisiting next quarter.

A governance framework approved this year may require revision next year.

The pace of change itself has become part of the risk model.

I’ve spent enough years around large organizations to know how unusual that is.

Technology normally moves first.

Regulation follows.

This time the gap felt much smaller.

That wasn’t the only thing that caught my attention.

The second was the pace of change everyone was struggling to describe.

One participant joked that by the time a governance committee approves an AI policy, the models have already moved on to the next version.

People laughed.

Mostly because it felt true.

The third observation was more subtle.

The smartest people in the room were not presenting certainty.

They were comparing notes.

Cybersecurity leaders, technology leaders, consultants, and business executives were all wrestling with the same challenge:

How do you build control systems around technology that is evolving faster than most organizational processes?

That question followed me home.

Not because I found a convincing answer.

Because I didn’t.

And perhaps that’s where enterprise AI stands today.

#AICybersecurity #CyberSecurity #AIGovernance
#AIRisk #EnterpriseAI #CISO #IndiaTech

Vimal Singh is Top 25 AI Leaders of 2025 with specialization in AI Automation & Enterprise Adoption. He has over a decade of experience in AI, People Analytics and Automation. He is also visiting faculty in AI at Tata Institute of Social Sciences (TISS), Mumbai

Please note - This is a series of my Building in Public “Body Language AI Tool”. Links below for different week experience

1. Week 0 - The need for Body Language Tool

2. Week 1 - Building in Public Humiliation?

After all I have had made an habit of Starting strong, struggling in the middle and giving up at last.

I’ve had AI systems before. My AutomateReporting Reporting Agents, ResumeGPT (NLP based Talent Acquisition tools), my voice based ViRa Agents

I thought let’s use a common use case which I could use, after internally debating I finalized Body Language Tool. Simple use case Computer Vision based AI to score my body language and give objective feedback.

I was wrong in ways that I ran out of vocabulary to define my problems.

This is my lived example of unfiltered story of how broken AI systems literally got me to lose sanity

First Assumption which Broke my confidence

I thought I will pick up a strong vision AI model prototype it on my GPUs. Improvise the UI and then my Body Language AI system will work

But I forgot a simple fact. Body Language is not monolithic it is multiple elements such as posture, tilt, movement, fidgeting, face expression and body movements.

As I was planning to use a smaller model these Data Points were too many to be tracked. After doing lot of research eventually settled for Yolo-v11-pose model. It is an open source model which captures 11 data points from human body. A strong start with overall a shaky architecture

Second Hurdle : the data scale

A live video feed analysis started generating huge amount of data. When I started analyzing each frame. My Prototype started lagging the video by 2-3 minutes. After 5 minutes of Run my Model context window would be spoiled and killed

I had to figure out something and pretty fast. I thought why not use sample videos of upto 5 seconds and run them for batch analysis.

This method was easier on GPU, who I could now see they were comfortable & cool not hot and weird

Third Hurdle: 11 data points too less

After running my second prototype I came to brutal realization 11 data point are too less to conclusively assign an objective Body Language score. While they could point major faux paus in Body language but can’t objectively cover subtlety which is the major aspects of Body language

This realization made me wonder what is the way around. It required a major architectural upgrade I will have to start recording the facial expressions. All this on Consumer GPU with standard webcam of 720p clarity

This required complete re-looking my archiecture, model choice and database

While technical complexity was one issue but the bigger issue was managing these huge computation on NVIDIA RTX 4060 GPU was asking too much from consumer GPU

Final Surrender: Incorporation of Facial Expression

But after evaluating all the options I had to surrender to my fate. Either I gave up the project or add Facial Expression into my AI tool

Necessity is mother of all inventions I had to learn to work with facial expression AI systems to incorporate them into body language tool.

I started using Quantized versions of Vision AI models sacrificing some level of performance will saving huge computation power.

After incorporating my changes my AI tool compiled. It worked, it was a strange feeling of short victory

But the victory was short lived as I ran into another major problem

To be continued

“If you are building in public something hard and the hard parts are different from what others say I love to hear”

Reply here or find me on LinkedIn

#BuildingInPublic #BodyLanguageAI #ComputerVision #YOLOv11 #PoseEstimation #FacialExpressionAI #AIBuilder #MachineLearning #NVIDIA #AIBuildingInPublic202

Vimal Singh is Top 25 AI Leaders of 2025 with specialization in AI Automation & Enterprise Adoption. He has over a decade of experience in AI, People Analytics and Automation. He is also visiting faculty in AI at Tata Institute of Social Sciences (TISS), Mumbai

₹8,000. A full Saturday. A room full of professionals who desperately wanted to look more confident.

The coach was brilliant. Posture tips. Eye contact frameworks. Hand gesture drills. We nodded. We took notes. We left feeling like we’d unlocked something.

Monday morning. Real interview. Real stakes.

I blanked on everything.

Not because the advice was wrong. Because I couldn’t see myself. I had no mirror. No feedback loop. No score. Just a fading memory of a Saturday seminar and a voice in my head saying “stand tall” while my hands did whatever they wanted.

Here’s the thing: body language coaching has a measurement problem nobody talks about.

The advice exists. The awareness exists. The gap between knowing and doing? Enormous. And completely invisible to the person trying to close it.

I’ve deployed 34 AI models inside real organizations. I’ve seen automation solve problems that humans couldn’t — not because humans weren’t capable, but because humans couldn’t see the problem clearly enough to fix it consistently.

Please note - This is a series of my Building in Public “Body Language AI Tool”. Links below for different week experience.

1. Week 1 - Building in Public Humiliation?

2. Week 2 - Does perfect AI Model Exists ?

So I asked myself a simple question: what if the same logic applied to your body?

What if instead of advice, you got a score?

What if instead of “maintain eye contact,” you got told — at timestamp 1:23 of your interview recording — that your gaze broke exactly when the pressure hit?

That’s what I built.

A Computer Vision AI that watches you. Scores you. Tells you exactly what’s off, in real time, without judgment, without ₹10,000 sessions, and without the forgetting that happens between workshop and boardroom.

And I’m building it in public. Every version. Every mistake. Every breakthrough.

This is Episode 1.

The question isn’t whether AI can coach your body language better than a human.

The question is: why did we accept unmeasurable advice for this long?

What body language advice have you received that you could never actually implement? Reply below — I'm building the next version around your answers.

#BodyLanguageAI #AICoach #JobInterviewHacks

Vimal Singh is an AI Faculty at TISS Mumbai, part of AutomateReporting and has deployed 34+ AI models inside real organizations. This is his Build in Public series.

“Vimal, we’ve trained close to 2,000 architects across our organization. Spent ₹3+ crores on structured programs. Domain experts, every one of them. 15+ years average tenure. We threw everything at this: workshops, certifications, hands-on labs, even brought in external trainers.”

He paused.

“Nothing shifted. They still don’t think like this. They see Claude. They see Copilot. They see tools. We need them to see a different way of building. And I have no idea how to make that happen.”

I sat with that for a moment. Not analyzing. Just sitting with what he’d named. Because in that confession was something I’d heard in different forms for three years, but never articulated: grief masquerading as resistance.

I’ve spent 13+ years deploying AI across Fortune 500s. I’ve sat through countless “transformation” programs. I’ve watched teams embrace change and watched them calcify. But this conversation felt different. Because for the first time, a senior leader was articulating something most organizations dance around:

Their best people are their biggest blockers.

This isn’t a story about poor training design or resistant cultures. This is a story about how expertise itself becomes an invisible cage.

And here’s what matters: The psychological wound is real. The identity threat is real. The cognitive dissonance is real. But all of that is downstream of something structural. Organizations create the exact conditions that make expertise a prison — rigid metrics, legacy system maintenance, efficiency rewards, inflexible incentive structures — and then they hire consultants to diagnose the resistance. They’re treating a symptom while reinforcing the disease.

Subscribe now

The Three Traps: Why Domain Experts Miss the Inflection Point

Let me walk through what I heard when we dug deeper.

Trap 1: The Tool vs. Mindset Confusion

When you ask architects about AI, here’s what they hear: “Use this new tool in your existing architecture.”

But that’s not what’s happening.

An LLM-first, agentic architecture isn’t an optimization layer on top of familiar patterns. It’s an inversion of the entire design logic. Traditionally, architects move downward: start with business requirements, translate to functional specifications, design system components, choose technologies that fit the design. It’s a waterfall of abstraction.

With LLMs, especially when you’re building agents with RAG pipelines, you design upward from capabilities and limitations. You start with: What can this model do? What will it confabulate on? How do I structure retrieval to reduce hallucinations? Where do I inject human judgment? Then you build the system around those constraints.

It’s not a different tool in the same architecture. It’s a different architecture paradigm.

Your architects know this intellectually. But their pattern-matching engine—the one refined over 15 years of making decisions—keeps trying to compress agentic systems into familiar categories. “Is this a service-oriented architecture thing?” “Is this a microservices problem?” “Can I apply API gateway patterns here?”

The answer to all three is: partially, but you’re missing the core shift.

This isn’t stupidity. It’s how the human brain works under cognitive load. When you encounter something unfamiliar, you grab the nearest familiar frame. It’s pattern-matching. It’s survival instinct. And it’s exactly what prevents learning.

Trap 2: Domain Expertise as Intellectual Quicksand

Here’s something nobody in HR says out loud:

Your most senior people are often the slowest learners in moments of discontinuity.

That VP had 2,000 architects. But the ones who’d been with the company for 15+ years? They weren’t leading the AI-first conversations. The ones making traction were 5–7 year architects. Newer enough to not have calcified around old patterns. Experienced enough to be dangerous.

I asked him why.

“Because the senior ones... they’ve solved this type of problem 50 times. They have a playbook. And every time we show them something new, they unconsciously fit it into that playbook.”

Exactly.

When you’ve successfully delivered complex enterprise systems using a particular mental model, that model becomes part of your identity. You’re not just someone who knows TOGAF principles—you are a systems thinker. You’re not just someone who understands microservices—you’ve mastered distributed systems. Your expertise is threaded through your self-image.

Now introduce something that doesn’t fit your mental model. Your brain does one of three things:

1. Rejects it: “That’s not scalable,” “That’s not enterprise-grade,” “We tried that before, it didn’t work.”

2. Absorbs it wrongly: Forces the new thing into the old framework, stripping away what makes it different.

3. Accepts it intellectually but doesn’t internalize it: Nods in meetings, passes training, but continues designing the same way.

All three look like resistance. But they’re not. They’re pattern-matching under threat.

The deeper issue? Domain expertise is built on compression. You’ve learned to look at a problem and instantly recognize its category: “This is a data consistency problem. Here’s how we solve data consistency problems.” Fifteen years of that builds neural pathways so deep that your brain wants to compress new information into existing categories.

When something genuinely new arrives—something that doesn’t compress, that requires you to think differently, not just know more—that’s cognitively exhausting. And exhaustion triggers defense mechanisms.

Trap 3: The Invisible Barrier

Here’s where it gets dark.

Every training program I’ve seen teaches what. What is RAG? What is LangGraph? What are prompt engineering best practices? What does a multi-agent system look like?

Nobody teaches why this feels threatening to someone who’s spent 15 years building the other way.

Because naming that threat would require acknowledging something organizations avoid:

Your identity is partly wrong now.

Not bad. Not useless. But insufficient. The patterns that made you successful are now partial solutions to a larger design space. And admitting that—really admitting it, not just intellectually accepting it—activates every defense mechanism you’ve built.

Burnout. Cynicism. Quiet resistance. “AI is overhyped,” “This is a consultant’s agenda,” “We should focus on stability, not chasing trends.”

These aren’t stupid statements. They’re grief. They’re the sound of someone realizing that 15 years of expertise is now context-dependent in a way it wasn’t yesterday.

Why Expertise Becomes a Prison

Let me zoom out for a moment.

So: What would guarantee an organization cannot adopt AI-first thinking?

Answer: Hire people with 15+ years of success in a different paradigm. Train them extensively in the new paradigm. Then expect them to think the new way while still living in the old way—still maintaining legacy systems, still making architectural decisions based on 15-year-old principles, still being measured on stability and cost-efficiency rather than exploration and adaptation.

You’ve basically ensured cognitive bifurcation.

Your senior architect has been trained on RAG pipelines. She knows what a retrieval-augmented generation system is. She can explain vector databases and embedding models. But at 9 AM, when she’s in a design review for a legacy system migration, her brain defaults to the mental model that’s worked 50 times. Because that mental model is efficient. It’s how she thinks under pressure.

By evening, she’s exhausted. The cognitive dissonance—knowing one thing, doing another—is like running two operating systems on the same processor. Burnout isn’t far behind.

This is why that VP’s training programs failed. Not because the content was weak. Not because the architects were stubborn. But because the organization was asking for a fundamental shift in how people think while structurally rewarding the old way of thinking.

The Great Depression of Expertise

I’m obsessed with the 1929 Great Depression. Not the financial mechanics—the behavioral shift. Within 18 months of the crash, entire populations rewired how they thought about money, work, and security. Cash hoarding. Make-do-and-mend culture. Willingness to do any work, any time. People’s cognitive hierarchies reorganized around scarcity.

What fascinates me is the timeline: institutional collapse happened in months. Behavioral rewrite took 18–24 months. And policy—policy came last. Governments were still debating responses while populations had already rewired themselves.

Why do I bring this up?

Because organizational shifts work the same way. When you encounter a genuine discontinuity—not an incremental change, but a rupture—the people closest to the old paradigm experience something like a controlled demolition of their expertise.

Except it’s not controlled. And it’s not fast.

Your architects are in that in-between space. The world has shifted (LLMs are real, they’re transformative, AI-first is no longer optional). But the infrastructure they work within—legacy systems, cost controls, stability metrics—hasn’t shifted. So they’re living in two worlds. And humans can’t live in two worlds for long without breaking.

Your architects are in that 18-month gap right now — and most organizations are still debating the response.

That VP didn’t have a people problem. He had a structural contradiction.

He was asking a fish to climb a tree. Then measuring how slowly it climbed.

The question isn’t: How do we train architects better?

It’s: Are you willing to change the tree?

The old framework says: Stability, principles, time-tested patterns.

The new framework says: Experimentation, emergence, probabilistic systems.

What Unlearning Actually Demands

Here’s the uncomfortable part.

You can’t teach someone to unlearn. You can create conditions for it. But the actual unlearning—that has to come from inside.

When I talked to the VP, I laid out what unlearning requires:

First: Accept that your mental model is now contextual, not universal.

This isn’t about being wrong. It’s about scope. For 15 years, your model worked because the problem space was well-defined: enterprise systems, bounded domains, predictable requirements, deterministic architectures. You became a master of that space.

But the space expanded. LLMs introduced probabilistic systems into a world of deterministic engineering. Your expertise is still valid—more valid, even, because you understand the downsides of determinism. But it’s no longer sufficient.

Accepting this means grieving. You don’t get to be the expert anymore. You’re a student again. And your ego—the thing that’s been reinforced for 15 years—doesn’t want that.

Second: Tolerate genuine confusion.

This is where training programs fail most spectacularly.

When you attend a workshop on RAG or LangGraph, the facilitator walks through examples. It looks coherent. By the end, you feel like you understand. You pass the assessment. You move on.

But real learning—especially in discontinuous domains—requires living in confusion. It means building something, having it fail in ways you don’t understand, debugging without a map, and then slowly, over weeks, developing new intuitions.

I know this because I’ve been that senior person.

Two years ago, I was convinced voice agents were just a speech recognition layer on top of traditional chatbots. I had deployed 34+ AI models. I understood orchestration. I understood HITL frameworks. I was comfortable. Confident. When I started building ViRa—our conversational AI—I kept trying to force agentic reasoning into the architecture I’d used a hundred times. The model would hallucinate. I’d treat it like a bug. Debug it like a regression. But it wasn’t a regression. It was a characteristic of the system.

For six weeks I sat in genuine confusion. Not because I lacked knowledge—I could explain multi-turn reasoning, token windows, context collapse. But I couldn’t feel the difference between building with deterministic systems and probabilistic ones. My intuitions kept defaulting to “fix the input, fix the output.” But with voice agents, the system emerges from incentive structures, not specifications.

It took that period of not-knowing, of building badly, of watching the model do things I couldn’t predict or prevent, before I could rewrite the mental model. That’s the work nobody talks about. That’s the discomfort most senior people avoid.

Most organizations don’t give senior people space to be confused. Confusion reads like incompetence. So senior people avoid it. They default to what they know. And they never actually learn.

Third: Relinquish the safety of patterns.

Patterns are cognitive compression. They’re how you move fast. “Oh, this is a cache invalidation problem. Here’s how you solve that.” Done.

But agentic systems don’t follow patterns in the same way. They emerge. You set up incentives, constraints, tool access. Then you watch what the model does. You iterate. You learn. It’s gardening, not engineering.

For someone who’s spent 15 years moving fast by pattern-matching, this is agonizing. It feels slow. It feels uncertain. It feels like you’re wasting time.

But that time is exactly where learning happens.

The Real Problem Isn’t People. It’s Systems.

Let me be direct about something.

That VP’s organization didn’t have a people problem. It had a structural contradiction.

They wanted architects to think AI-first. They measured them on architectural stability. They had them maintain legacy systems. They paid them based on how efficiently they deployed, not how adventurously they experimented. And they gave them three hours of training per quarter while keeping their day jobs.

That’s not a people problem. That’s a system designed to prevent the exact change they wanted.

It’s like asking a fish to climb a tree, then blaming the fish for being slow.

The question isn’t: How do we train architects better?

The real question is:

Are you willing to structurally reorganize your metrics, incentives, and work allocation to make room for discontinuous learning?

Because if the answer is no—if you want transformation without changing how you measure, reward, and structure work—then you’re not trying to transform. You’re trying to have it both ways. And you’ll get neither.

When Expertise Meets Inflection Points

Here’s what I told that VP when we finished talking.

Your 2,000 architects didn’t fail because they’re not smart enough. They failed because you asked them to adopt a new paradigm while reinforcing the old one. You created a Frankenstein: people with knowledge of the new thing, but incentives to stick with the old thing.

And then you blamed the gap on execution.

He went quiet. “So what do we do?”

I laid out three options, each one honest about the cost.

Option 1: Accept that transformation takes time. Not six months. Not a year. 18–24 months of systematic unlearning, where you create safe space for experiments to fail, where you explicitly reduce pressure for stability for certain teams, where you celebrate learning over efficiency. That’s structurally difficult. Most organizations can’t sustain it.

Option 2: Build a skunk works. Pull 100–200 architects who are most curious, least attached to legacy patterns, and have them operate under different metrics. Let them fail loudly. Let them teach the rest. This works, but it fractures the organization.

Option 3: Accept the transition cost and hire differently. Your 2,000 domain experts are anchored to the old paradigm. Bring in 500 people who’ve never known anything but AI-first thinking. Let them set the tone. Retire the legacy systems faster. This is expensive and painful, but it’s honest.

He nodded slowly. “We’re trying to do all three at once and failing at all of them.”

I don’t know what he decided. I haven’t heard from him in eight months. But I think about him sometimes, because he named something most leaders never will:

We want transformation without the cost of transformation. We want our people to become someone else while we keep measuring them by who they were.

That gap—between the transformation you want and the conditions you’ve created—is where expertise becomes a cage.

Your expertise isn’t wrong. It’s just no longer sufficient.

There’s a difference between those two things—a difference most people spend years learning.

Tags: #AIAdoption #Unlearning #EnterpriseArchitecture #LeadershipTransformation #FutureOfWork

Vimal Singh is Top 25 AI Leaders of 2025 with specialization in People Analytics & AI Automation. He has over a decade of experience in AI, People Analytics and Automation. He is also visiting faculty in AI at Tata Institute of Social Sciences (TISS), Mumbai

When connect with HR Leaders across industries, you can easily sense AI deployment projects in HR aren’t on track

These AI projects aren’t struggling due to Technology complexity but due to lack of Quality data which is a precursor to most Agentic AI systems.

HR data had always been an afterthought, something owned by Junior Employee working in HR Analytics or HR Ops team. It’s definitely not the top concern for any of CHROs or HR Leaders.

But AI demands Data Sanity and quality, but since so far HR Leaders weren’t owning the data, it has been mess

This data mess is now costing embarrassment to HR function as Project deployment is getting delayed and being costly.

While Marketing and Operations have been always Numer loving functions their Data has been in much better shape compared to HR Data

Once upon a time, an HR leader had a dream: a single, unified report that would tell the unfiltered truth about the workforce. That dream ended the moment the report landed on a senior executive’s desk.

HR reporting is supposed to bring clarity. Instead, it often creates confusion, distrust, and endless cycles of “format fixing.” Why?

Because HR reports don’t just fail — they get sabotaged in three specific ways: inconsistent formats, mismatched data, and manipulation to please higher-ups.

1. The Format Carousel: Changing Just for the Sake of It

Every new CHRO or CFO wants their version of the report. A new dashboard here, a different KPI there.

What was “critical” last quarter is now irrelevant. The reporting team spends more time beautifying slides than analyzing data.

And just when you think you’ve nailed it, the format changes again. The goalpost keeps shifting.

A perfect example of how organizations treat HR data like a Bollywood script — rewritten a hundred times before release.

HR dashboards have become like IPL team selections — constant shuffling, endless debates, and still, no one is happy with the final squad.

2. The Data Doesn’t Match (And Never Will)

Finance has headcount numbers. IT has access logs. HR has attrition data. The three never align.

Why? Because each function uses different definitions, different systems, and different reporting cycles.

HR’s FTE count includes people on notice period, Finance excludes them, and IT doesn’t even know they exist.

Result? The CEO asks, “How many employees do we have?” And three departments give three different answers.

It’s like a Game of Thrones battle council — everyone claims to have the right numbers, but no one really knows what’s happening on the ground.

3. The ‘Make It Look Good’ Syndrome

Not all data is created equal. Some data gets “adjusted” before it reaches the C-suite.

• Attrition looking high? Change the denominator.

• Engagement survey results low? Present only the top quartile.

• DEI numbers stagnant? Remove the department that’s dragging the average down.

By the time the report reaches the top, it’s no longer a report — it’s a fairy tale.

It’s like Luke Skywalker walking into a Jedi temple hoping for ancient wisdom, only to find a heavily edited version of the truth that suits the narrative of the day.

The End Result: No One Trusts HR Reports

Leaders stop believing the numbers. Business teams run their own calculations.

And HR, instead of driving decisions, becomes a compliance function producing numbers that look right but mean nothing.

The Way Forward: Radical Transparency

• Lock the Format for a Year: No redesigns, no last-minute “Can we add this one metric?” requests. Keep it stable.

• Align Definitions Across Departments: One source of truth. Either HR, Finance, or IT owns it. Not all three.

• Report the Truth, Not the Expectation: If the numbers are bad, they’re bad. Hiding them doesn’t fix anything.

HR data should drive strategy, not entertain executives like a Game of Thrones plot twist.

The moment HR reporting stops being about optics and starts being about insights, organizations will finally get what they’ve been asking for: the truth.

Vimal Singh is Top 25 AI Leaders of 2025 with specialization in People Analytics & AI Automation. He has over a decade of experience in AI, People Analytics and Automation. He is also visiting faculty in AI at Tata Institute of Social Sciences (TISS), Mumbai

I asked, “So, what did you learn?”

She smiled. “That I didn’t understand AI. And neither did the vendor.”

Silence.

Not the quiet kind. The loud, echoing kind—the kind that tells you a new skill isn’t optional anymore.

Why HR Can’t Afford to Stay AI-Illiterate ?

Gartner says 80% of HR teams will use AI by 2026. But let’s not quote Gartner like scripture.

Instead, ask this: who’s shaping the algorithms that decide who gets hired, who stays, who grows?

Let me ask this: who else understands humans better than HR?

So why should HR leaders learn AI?

• Because if you don’t, someone else will build systems that make people decisions without HR wisdom.

• Because your next competitor might be a team of three people and one fine-tuned GPT model.

• Because when you understand AI, you stop fearing it—and start shaping it.

But First, Learn Its Language.

No, I don’t mean Python (though it helps).
I mean how AI thinks.

Learn about decision trees, neural networks, and yes—Large Language Models (LLMs)—but don’t stop there. AI isn’t equal to LLM. That’s like saying HR is just recruitment.

Understand how algorithms “see” performance data. Understand bias in training data. Spend a week going native—play with open-source models, watch them stumble, refine your prompts, and notice how they “think.”

Only then will you stop copy-pasting ChatGPT prompts and start leading with AI.

Start Small. Stay Curious. Scale Wisely.

Don’t automate HR overnight. Pick one problem:

• Can AI shortlist resumes faster?

• Can it predict training needs?

• Can it save your team 8 hours a week? (Ours did.)

Try. Fail. Refine. Repeat.

Three Questions to Begin With:

1. Which decision in your team is made mo

   stly by gut-feel today?

2. Which HR process has tons of data but no insights?

3. Where are your teams overwhelmed, and would guided AI assistance help?

These aren’t tech questions. They’re leadership ones.

HR + AI = Human Reimagined.

The future isn’t AI prompts—it’s questions only humans dare ask.

What’s your first step with AI in HR? Drop a comment or share your story!

#HRTech #ArtificialIntelligence #Leadership #FutureOfWork #HR4.0

Vimal Singh is an expert in People Strategy and AI. He has over a decade of experience in People Strategy and Automation. He is an alumnus of prestigious Tata Institute of Social Sciences (TISS), Mumbai

A spreadsheet opens. Rows stretch endlessly. Numbers whisper, "Are you sure about us?" A sigh follows. Another late night.

It’s just one report. Then another. And another.

Before you know it, half your week is gone, buried under data checks, formatting fixes, and last-minute “urgent” tweaks.

Manual reporting—the silent killer of HR productivity—doesn’t just waste time. It erodes accuracy, burns out teams, and damages HR’s credibility.

The Illusion of Control

HR leaders often defend manual reporting.

"It keeps me close to the numbers."
"We need to verify everything ourselves."
"Automation? We’re not ready yet."

Sounds logical—until you realize manual reporting isn’t control. It’s a full-time job nobody signed up for.

The Hidden Costs HR Rarely Talks About

1. Data Inconsistencies – The Trust Killer

Ask three different teams for headcount. You’ll get three different numbers.

• Finance pulls from payroll.

• HR Ops has a different version in Excel.

• Talent Acquisition swears by their hiring tracker.

When leadership asks for a “final” number, no one knows which version is right. HR becomes the department of best guesses.

2. Data Quality – Garbage In, Garbage Out

Messy data isn’t just an IT problem—it’s an HR credibility crisis.

• Duplicate employee records

• Inconsistent job titles (Is "Senior Associate" the same as "Sr. Associate"?)

• Missing fields (Who's responsible for fixing them?)

Decisions on hiring, retention, and compensation are only as good as the data behind them. If your reports are built on broken foundations, so are your strategies.

3. Data Ownership – Everyone’s Job, No One’s Job

Who owns HR data? Payroll? IT? HR Ops?

Everyone assumes someone else is responsible. No one takes full accountability.

The result? Multiple versions of the truth floating around, each telling a slightly different story. No one knows which one to trust.

4. Time Drain – The Silent Thief

HR professionals spend 30–50% of their time generating reports instead of analyzing insights.

Hours disappear into:

• Cross-checking numbers

• Reformatting tables

• Fixing broken formulas

By the time the report is “ready,” the data is outdated. And the cycle repeats.

5. Burnout – The Ultimate Price

HR isn’t supposed to be about formatting cells—it’s about people.

Yet, HR leaders—who should be driving strategy—end up acting as human spreadsheets, caught in a never-ending reporting loop.

Late nights, last-minute changes, leadership breathing down your neck for “one more tweak.” It’s exhausting.

The Breaking Point: When HR Becomes a Data Janitor

At some point, every HR leader realizes: Manual reporting is unsustainable.

The real question isn’t if automation is needed—it’s how much longer you’ll tolerate the pain.

The irony? The same HR teams advocating efficiency, engagement, and well-being for employees are often trapped in outdated, soul-crushing reporting cycles.

Maybe it’s time to stop justifying the pain and start eliminating it.

What’s your experience with manual reporting? Let’s talk.

#HRReporting #AutomateReporting #AttritionData #AttritionConundrum #AIHR

Vimal Singh is an expert in People Strategy, Big Data Analytics & Automation. He has over a decade of experience in People Strategy and Automation. He is an alumnus of prestigious Tata Institute of Social Sciences (TISS), Mumbai

There’s a moment in every HR professional’s life when they realize they’re not just managing burnout—they're living it. And the irony? The very people hired to protect employee well-being are often the ones with the least of it. This is the irony of my life.

The Unseen Battle

HR is not for the faint of heart. It’s a world where we navigate layoffs in the morning, engagement surveys at noon, and a crisis by 4 PM—only to be asked at 5 if we can "do something fun for the team."

“Chingari koi bhadke, to saawan usse bujhaye...”

But what happens when the aag(fire) itself is unstoppable? When HR—the ones dousing corporate flames—find themselves engulfed?

It’s firefighting with no fireproof suit.

It’s therapy without a therapist.

It’s smiling while your inbox bleeds.

And somewhere in between answering emails at 11 PM and pretending performance reviews aren’t a political minefield, burnout creeps in.

When I Hit the Wall

Last month, I felt it. The weight of HR, the endless cycle of managing emotions, policies, and expectations—all while my own energy drained like a leaky tap. A 14-hour workday ended with an exhausted scroll through my inbox, only to see another "urgent" email that could have waited until morning. But I responded anyway, because that’s what we do, right?

Then came the moment: staring blankly at my laptop, no energy to type, no will to care. Not even the usual resolve to “power through.” Just...emptiness.

Burnout doesn’t announce itself with sirens. It seeps in, quiet and relentless.

“Jo apne hi paani mein, ghar doobe, to kya kare?”

Why HR Burnout is Different

• Emotional Labor Tax: People cry, vent, and confess things to HR they wouldn’t tell their managers. And you? You absorb it all.

• The "Fix-It" Burden: HR is expected to be the architect of culture, the protector of employees, and the enforcer of business goals—simultaneously.

• The Compliance Vice: One misstep, one poorly worded email, and you’re suddenly the villain in a compliance drama.

• Thankless Success: If HR does its job well, no one notices. If something goes wrong, HR is the first in line for blame.

HR professionals often find themselves drowning in their own work, unable to access the very lifelines they extend to others.

Signs You’re Burning Out (But Won’t Admit It)

1. You avoid people. The irony of HR fatigue: the more burnt out you are, the less you want to deal with humans.

2. Your empathy tank is empty. "Oh, your manager gave you constructive feedback? Tell me more about your suffering."

3. You fantasize about a job where ‘people’ isn’t in the title. Data science, beekeeping, lighthouse keeper… anything.

4. Every email feels like a potential lawsuit. Even "Happy Friday!" seems risky.

5. You dread HR ‘fun’ initiatives. Organizing a morale-boosting event when your own morale is six feet under? The peak of irony.

The Exit Ramp (Or, How to Burn Bright Without Burning Out)

• Set Boundaries Ruthlessly. You are not an always-on call center.

• Find an HR Peer Group. You need people who get it—vent, strategize, recharge.

• Use Your Own Policies. Mental health days? Take them. Flexibility? Demand it. Lead by example.

• Automate and Delegate. You are not a workflow machine. Technology exists—use it.

• Reclaim the Why. You entered HR for a reason. Find it again. Not in spreadsheets, not in late-night emails, but in the impact you make.

Final Thought

HR isn’t broken, but how we treat our HR teams might be. If we truly care about employee well-being, that has to start with the people responsible for it.

“Raat bhar ka hai mehmaan andhera...”

Burnout is not permanent. It feels endless, but the dawn is always waiting. Even firefighters need water.

And about Vimal? He needs a break.

#Burnout #WorkLifeBalance #StrategicHR #WellBeing #MentalHealth

Vimal Singh is an expert in People Strategy, Big Data Analytics & Automation. He has over a decade of experience People Strategy and Automation. He is an alumnus for prestigious Tata Institute of Social Sciences (TISS), Mumbai

At the end of my HR Analytics lecture, a student asked, “"Is analytics just about knowing statistics or using tools like Power BI, Python, Pandas, and Tableau?"

I couldn't get the question off my mind.


I think analytics is a mindset, not just a skill set of tools. It involves using statistics to distill difficult, individualized queries into useful findings.


For instance:

1. Was Alauddin Khilji a superior ruler than Akbar the Great?

2. Compared to earlier generations, is Generation Z happier?

3. Who is most likely to win the upcoming Indian Premier League?
   

Analytics Mindset

Each of the above question requires multi-dimensional thinking.

Consider the first: we would have to specify what constitutes a "good ruler"—security, social reforms, per capita income, or other elements.

These dimensions are defined by us, not by tools.

Asking the Right questions, establishing the correct dimensions, and using data to find meaningful answers are the key components of analytics, not tools.

Tools vs mindset

Tools are just enablers. As professionals, our true role is to think critically, define what matters, and transform data into impactful decisions.

Analytics is a Mindset, Not Just Tools


#HRAnalytics #WorkforceInsights #Python #AI #Automation

Bibliography

1. https://hbr.org/2020/03/whats-the-best-approach-to-data-analytics

2. https://www.forbes.com/councils/forbesbusinesscouncil/2024/04/12/unlocking-the-power-of-analytics-how-to-adopt-a-data-driven-mindset/

3. https://sloanreview.mit.edu/series/the-new-leadership-mindset-for-data-analytics/

Vimal Singh is an expert in People Strategy, Big Data Analytics & Automation. He has over a decade of experience People, Strategy and Automation. He is an alumnus for prestigious Tata Institute of Social Sciences (TISS), Mumbai.