People analytics has moved well beyond headcount charts and attrition spreadsheets. Indian companies are now using engagement signals, performance data, and predictive models to spot risks before they become resignations, identify successors before roles fall vacant, and connect workforce decisions directly to business outcomes. For HR leaders, the challenge is no longer whether to build an analytics function, but how to build one that earns a seat at the Board table and changes the decisions that get made there.
In this conversation, Vishal Manchanda, Chief Human Resources Officer at Brick2Wall, walks us through the architecture, data choices, and modelling decisions that go into building a credible people analytics stack. He talks about why decision proximity matters more than data availability when picking your first integrations, why legacy payroll systems and homegrown ATS platforms tend to hold the messiest data, and how his first predictive model on HiPo attrition revealed that manager tenure mattered more than pay. He also gets honest about what has not worked, from culture-fit scoring that quietly reinforced bias to productivity models that captured activity rather than output.
TPB Team: When you start building people analytics, how do you decide which data sources to integrate first into your analytics stack?
Vishal: We need to focus on where the business needs us the most. Most teams default to what is easiest: headcount, attrition, and tenure. This is good reporting, but not insightful analytics that will create an impact.
I prioritise data sources by ‘decision proximity’: which workforce decisions, if made better, have the most immediate business consequence? That is the primary integration point. Typically, it’s performance plus engagement plus HRIS around a critical talent segment the business is losing sleep over.
One sharp insight that saves 20 Lacs in regrettable attrition earns more organisational trust than six months of dashboards. The rule is to build credibility fast, then expand the stack.
Integration should be linked to the decision impact, and not data availability.
TPB Team: Which HR systems are the hardest to extract clean, reliable data from in your experience?
Vishal: Legacy payroll systems and homegrown ATS platforms.. by a significant margin!
Payroll systems, especially anything built on-premise before 2010, were designed for compliance, not analysis. Data lives in flat files, field definitions shift across business units, and nobody documented the logic behind half the codes still running in production.
Homegrown ATS platforms are worse because the inconsistency is invisible. Recruiters entered data differently across teams, job families were never standardised, and what looks like structured data is often free-text fields someone once decided to report on.
Most problematic are the LMS platforms. Learning completion data sounds clean, but it rarely is. Courses get recategorised, completion thresholds change, and linking learning investment to performance outcome is almost always a custom engineering problem.
The messiest data usually lives closest to the most important decisions. Instead of avoidance, there is a strong need to invest in data governance before you invest in analytics tools.
TPB Team: How do you handle data quality issues that come from inconsistent manager inputs across business units?
Vishal: Inconsistent manager input is not a data problem, but a process design problem that shows up in your data.
The root cause is almost always the same: managers never understood what they were capturing or why it mattered. That context gap is where quality collapses.
Three things that actually work:
- Constrain input before it happens. Fewer free-text fields, tighter rating scales, mandatory fields. Every open text box is an invitation for inconsistency.
- Make the data visible to the person creating it. When managers see how their inputs compare to peers, behaviour shifts faster than any training can achieve.
- Treat outlier patterns as signals. A unit where 90% of employees are rated “meets expectations” is telling you something about the manager, not the team. Investigate it, then feed that finding back to your HRBPs with context.
You will never fully solve this. What you can do is design systems where data quality is the path of least resistance.
TPB Team: What was the first predictive model you deployed, and what business question was it answering?
Vishal: Attrition risk among HiPo’s in a high-growth business going through rapid scale.
We were losing people we could not afford to lose, and the exit interviews were telling us very little. By the time someone resigned, the decision was weeks old. We needed to get ahead of that.
The model pulled together performance ratings, internal mobility history, manager tenure, compensation positioning relative to market, and engagement survey scores. The insight was in how these variables interacted, not in any single signal alone.
What surprised us most: compensation was rarely the primary driver. Managers who had been in the role for less than eighteen months, combined with low internal mobility in the prior two years, were a far stronger predictor than pay gaps. That finding alone changed how we prioritised manager development investment.
The business impact was tangible. Retention of the flagged population improved meaningfully in the following year, and the CHRO function gained credibility it had not previously had in strategic conversations.
The lesson I carried forward: your first model does not need to be sophisticated. It needs to answer a question the business is already losing sleep over, and deliver an answer nobody expected.
TPB Team: How do you decide whether a problem actually needs a predictive model versus a good dashboard?
Vishal: A dashboard focuses on “what happened.” A model answers “what will happen if we do nothing.” If leadership is still debating what the problem is, build a dashboard. If they know the problem and need to act before it escalates, build a model.
Here are the test I apply: is there still a decision to be made, or is timing the real issue? Dashboards inform decisions. Models change when you make them.
The second test is consequence. If being wrong is recoverable, a dashboard is enough. If being wrong means losing a critical talent segment or a failed succession, you need a model that quantifies risk and prioritises intervention.
One reality most analytics teams ignore: a model you cannot operationalise is just an expensive insight. Before building anything, ask who will act on the output and what they will do differently. If that answer is vague, the organisation is not ready. Build the dashboard first, mature the decision culture, then return.
TPB Team: Which AI capabilities have genuinely changed how your analytics team works day to day?
Vishal: Three things, specifically.
- Natural language querying has removed the bottleneck between business questions and data access. HR business partners who would previously wait days for an analyst to pull a report can now interrogate the data themselves. That shift alone has changed the quality of conversations HRBPs have with business leaders.
- Automated anomaly detection has replaced a lot of manual pattern hunting. The team no longer spends hours looking for what is wrong with the data. The system surfaces it, and the team spends that time figuring out what to do about it.
- Generative AI has changed how we synthesise qualitative data at scale. Exit interview themes, engagement open-text responses, candidate feedback, all of it can now be analyzed in hours rather than weeks. The nuance we were previously missing because nobody had time to read thousands of comments is now consistently in the room when decisions get made.
What has not changed: judgment. The model tells you a population is at risk. Someone still has to decide what that means in this business, with this manager, in this moment. That part remains entirely human, and I think it should stay that way.
TPB Team: How do you ensure your models stay free of bias when predicting attrition or performance outcomes?
Vishal: Honestly, it simply needs to be managed continuously.
Bias in predictive models is a lifecycle problem. A model trained on historical performance data inherits every bias embedded in how performance was assessed, who got stretch assignments, whose potential was noticed and whose was not. Cleaning the training data helps. It does not eliminate the problem.
What has worked in practice:
- Disaggregate your model outputs before you act on them. If your attrition risk scores look different across gender, ethnicity, or age cohorts in ways the underlying performance data does not explain, the model has learned something it should not have. That audit needs to happen before deployment, not after.
- Include people in the loop who are not data scientists. The pattern a model cannot see, an HRBP who knows the business often can. Diverse interpretation catches what diverse data cannot always fix.
- Retire models on a schedule. A model built eighteen months ago was trained on a workforce and a business context that may no longer exist. Stale models produce confident answers to questions that have already changed.
Some of the most biased outputs I have seen came from models built with the best intentions and the most rigorous methodology. Bias auditing cannot be a one-time checkbox. It has to be a standing practice with someone accountable for it.
TPB Team: How did you build the technical capability inside your HR team to support the analytics work?
Vishal: Slowly, and with more resistance than I expected.
The first decision was the most important: I did not try to turn HR generalists into data scientists. That path produces mediocre analysts and loses good HR professionals. I built a small team with genuine technical depth and focused on raising data literacy across the broader HR population around them.
Data literacy for HR means something specific. Reading a confidence interval, questioning a model’s assumptions, and translating a finding into a business recommendation. Not writing code. That distinction matters enormously when designing any capability program.
I hired for curiosity before credentials. The best people on my analytics team came from unexpected places, supply chain, behavioural science, and organisational psychology. Domain diversity catches blind spots that a homogenous HR-trained team will consistently miss.
The third move was embedding analysts with business units rather than centralising everything. Proximity to real decisions accelerates capability faster than any training program.
What I would do differently: invest in data governance infrastructure earlier. Capability without clean data is sophisticated guesswork.
TPB Team: How do you translate model outputs into language that resonates with the Board members?
Vishal: I would say, lead with the business consequence.
Board members do not need to understand how the model works. They need to understand what it is costing the business to ignore what it is saying.
I never walk in with accuracy scores. I walk in with: we have 23 people in a critical talent segment likely to leave in six months. Replacing each costs 1.5 times their salary. That is a ₹₹ problem we can see coming and partially prevent.
Two things that consistently work: connect the finding to a decision they already own, growth, risk, and succession. And be honest about what the model cannot tell you. Boards have strong instincts for overconfidence.
Acknowledging the limits of the analysis builds more credibility than projecting false certainty.
The measure is not whether they understood the analytics. It is whether they made a different decision because of it.
TPB Team: Which people metrics does the Board genuinely care about beyond the standard headcount and attrition numbers?
Vishal: The metrics that consistently hold board attention are the ones with a direct line to business continuity or growth. These include succession depth for the top 50 critical roles, not just the C-suite; internal mobility rates as a proxy for organisational health and talent utilisation; revenue per employee tracked over time as a measure of workforce productivity, not just efficiency.
Increasingly, boards want to see quality of hire measured 12 to 18 months out, not at the 90-day mark. And in organisations going through transformation, change adoption metrics are tied to business outcomes rather than training completion rates.
What boards do not care about: HR process metrics dressed up as business metrics. Time to fill and cost per hire are operational numbers. These might be good to present internally, not in the boardroom.
The question I always ask before a board presentation is: if this number moved significantly in either direction, would it change a capital allocation decision? If the answer is no, it does not belong on that slide.
TPB Team: How do you present uncertainty and confidence intervals when sharing predictions with senior leadership?
Vishal: My advice is to never lead with the statistical language. Translate it before it enters the room.
Confidence intervals become ranges. Instead of “the model predicts attrition with 73% confidence,” I say “our best estimate is 18 to 24 people leaving this segment, and we are reasonably confident the real number sits in that range.” Same information, no jargon, no defensiveness from people who distrust numbers they do not understand.
The second move is separating signal strength from recommendation strength. A weak signal can still justify a low-cost intervention. A strong signal might still require more investigation before acting. Senior leaders conflate the two constantly, and it is the analytics leader’s job to keep them distinct.
The one thing I never do is hide uncertainty to make a cleaner story. Leaders who feel misled by overconfident predictions stop trusting the analytics function entirely. One honest “we do not know yet” builds more long-term credibility than ten polished decks.
TPB Team: What analytics use cases failed despite looking promising on paper when you started building?
Vishal: Two stand out.
A culture fit scoring model during recruitment. The model learned to replicate existing cultural patterns rather than identify genuine cultural contributions. In practice, it became a sophisticated tool for hiring people who looked like the people already there. We shut it down.
The second was a productivity model for knowledge workers. Rich data, clear hypotheses, executive sponsorship. The problem was that productivity in complex roles resists clean measurement. What the model captured was activity, not output. Busy people scored well. High-impact people who worked differently scored poorly.
The pattern in both failures was identical: we mistook data availability for problem solvability.
The question I now ask before any new use case: are we measuring the thing, or a shadow of the thing? That question alone has saved significant wasted investment.
TPB Team: How do you measure the actual business impact of your people analytics investments over time?
Vishal: Most analytics functions measure their own activity: reports, models deployed, and dashboards. That is output tracking, not impact measurement.
I measure impact by tracing interventions to outcomes with a time lag built in. If a retention model flagged a population in Q1 and we intervened, I want to see that cohort’s actual attrition twelve months later compared to a similar unflagged group. That delta, converted to replacement cost avoided, is the number that belongs in an impact report.
Three things I track consistently: decision velocity among business leaders, regrettable attrition in analytically monitored populations versus unmonitored ones, and HRBP time shifted from reporting to advising.
The honest challenge is attribution. Many factors influence outcomes simultaneously. I have found it more credible to claim contribution rather than causation and build a consistent body of evidence over time.
TPB Team: What advice would you give an HR leader just beginning their analytics journey from spreadsheets today?
Vishal: The most common mistake is investing in tools and talent before the organisation has developed the habit of asking data-driven questions. You end up with analytical capability serving a culture that is not ready to use it.
Start with one painful business problem that leadership already cares about. Not an HR problem. A business problem that happens to have a people dimension. Build something simple that speaks directly to that problem, and make the insight impossible to ignore.
Get one senior business leader, not an HR leader, visibly invested in what you are building. Credibility in analytics travels faster through business sponsorship than through HR advocacy.
And resist the pull toward sophistication too early. A clean, well-interpreted spreadsheet that changes a decision is worth more than a model nobody acts on. Mature the questions before you mature the methods.
What stands out across Vishal’s responses is a steady refusal to confuse sophistication with impact. The strongest people analytics functions, in his view, are built on simple questions the business is already losing sleep over, clean data governance laid down before the dashboards arrive, and a willingness to say “we do not know yet” when the model cannot. For HR leaders moving from spreadsheets to predictive models, the path forward is less about tools and more about credibility, one well-answered business question at a time.
