Burnout is usually discussed as a management issue, a staffing issue, or a culture issue. In workforce-heavy industries, it can also be a software issue.
When enterprise systems are slow, fragmented, confusing, or unreliable, the pressure does not stay inside the technology organization. It moves directly to managers, supervisors, support teams, and frontline employees. People spend more time double-checking information, chasing missing data, correcting errors, and working around tools that were supposed to help them.
Anil Kumar Karumuru, Director of Engineering at UniFocus, has spent much of his career working on enterprise software platforms, workforce management systems, and data integrations. His view is simple: architecture is not just a backend concern. In operational environments, architecture directly shapes the employee experience.
“If the software adds complexity in that moment, it becomes part of the problem,” Karumuru says.
That idea sits at the center of his approach to enterprise modernization. The goal is not only to build scalable systems. It is to build systems that reduce cognitive load, remove unnecessary friction, and help people make better decisions under pressure.
In high-stress industries, even small moments of software friction can have a larger impact than technology teams sometimes realize. A confusing alert, a missing schedule, a broken data handoff, or a screen that forces too much manual interpretation can create pressure at exactly the wrong time. Karumuru believes the next generation of enterprise software must be designed with that reality in mind.
Reducing cognitive load is an engineering responsibility
Frontline managers are often expected to make fast decisions with limited time, attention, and context. They may be dealing with staffing changes, overtime risk, missed punches, service demands, compliance rules, employee concerns, and customer expectations all at once.
In that environment, software has to be clear. It cannot simply present more data and expect the user to figure out what matters.
Karumuru believes enterprise platforms should be designed to detect, prioritize, and surface exceptions clearly. Instead of forcing managers to dig through reports, the system should help them understand where attention is needed.
“The architecture should be able to detect, prioritize, and surface exceptions clearly,” he says.
That requires work behind the scenes. Data has to be connected. Rules have to be reliable. Alerts have to be meaningful. The interface has to stay focused on action, not clutter.
When done well, the user does not see the complexity. They see a clear signal. That is the difference between software that adds pressure and software that supports the work.
Karumuru often looks at cognitive load as a product and architecture problem together. A screen may look simple, but if the user cannot trust the data behind it, the experience is still stressful. A report may contain all the necessary information, but if the user has to manually interpret what matters, the system has not fully done its job.
This is why exception-driven design matters. The goal is not to hide important information. The goal is to help users focus on what requires action. In workforce management, that could mean surfacing overtime risk, missing punches, staffing gaps, scheduling conflicts, or integration failures in a way that is timely and easy to understand.
Reducing cognitive load does not mean oversimplifying the business. It means designing the system so users do not have to carry unnecessary complexity in their heads.
Empathy has to be translated into engineering decisions
Empathy is often treated as a design principle, but Karumuru believes it has to show up in engineering execution.
“In high-stress industries, empathy starts with understanding the environment the user is operating in,” he says.
That means engineering teams need to understand what happens when a system fails. A missed integration is not just a failed job. It may mean a manager cannot trust the schedule. A confusing exception may mean support has to intervene. A delayed alert may mean a client experiences the issue before the organization responds.
“If engineering is disconnected from those signals, empathy becomes theoretical,” Karumuru says.
This is why he values operational signals such as support tickets, escalations, adoption trends, incident patterns, workflow abandonment, manual retries, and recurring user confusion. These signals show where the system is creating friction.
Once teams understand those patterns, empathy becomes more than a value statement. It becomes prioritization. It influences what gets fixed first, what needs better monitoring, where automation can help, and where the user experience needs to be simplified.
Karumuru believes engineering empathy is not about making teams less accountable. It is about making accountability more meaningful. When teams understand the operational consequences of their decisions, they can make better tradeoffs. They can distinguish between a low-priority technical cleanup and a recurring issue that creates real user pain.
In enterprise software, the distance between an engineering decision and a user experience can feel large. But in practice, the connection is direct. A brittle integration, a slow deployment process, weak observability, or unclear ownership can all show up as friction for someone else.
That is why Karumuru sees empathy as a practical discipline. It has to be supported by metrics, feedback loops, support data, and operational visibility. Without those signals, teams may believe they are improving the product while users continue to struggle.
Clean backend processes create cultural value
Enterprise software users rarely think about backend architecture when everything is working. They notice it when something breaks.
If employee data, job assignments, schedules, labor structures, or payroll-related information does not flow cleanly, people quickly lose confidence in the system. They create backup spreadsheets. They manually validate data. They question reports. They hesitate to trust automation.
“If employee data, job assignments, schedules, labor structure, or payroll-related information does not flow cleanly between systems, the impact shows up very quickly,” Karumuru says.
For him, that is why integration quality is not just a technical concern. It is a trust concern.
“When the backend process becomes cleaner and more predictable, the culture shifts,” he says.
Reliable systems reduce defensive work. They give operations teams confidence that the information they are seeing is accurate. They allow managers to spend less time reconciling data and more time leading their teams.
That is how technical discipline turns into organizational value. The architecture may be invisible, but the relief it creates is very real.
Karumuru believes this is especially important in workforce-heavy businesses because so many operational decisions depend on connected data. Employee records, job assignments, labor structures, schedules, punches, forecasts, and pay-related information all interact. When one part of that chain is unreliable, people start questioning the entire system.
Over time, that lack of trust changes behavior. Users stop relying on the platform as the source of truth. Managers create their own tracking methods. Support teams spend more time explaining inconsistencies. Engineering teams spend more time reacting to symptoms instead of solving root causes.
Clean backend processes can reverse that pattern. When data flows predictably, and issues are surfaced clearly, people begin to trust the system again. That trust has cultural value. It reduces stress, improves confidence, and allows teams to focus on the work instead of constantly validating the tool.
Modernization has to account for human debt
Legacy systems are often described as technical debt. Karumuru believes that the description is incomplete.
“If we only look at legacy systems as technical debt, we miss the human debt that has built up around them,” he says.
Over time, people adapt to the limitations of software. They memorize workarounds. They create side processes. They learn which screens to avoid, which reports to double-check, and which steps require manual follow-up. Those behaviors become part of the operation, even when they are inefficient.
Modernization efforts can fail when they ignore that reality.
“Before changing the architecture, I try to understand the operational reality around the system,” Karumuru says.
For him, effective modernization starts with observation. Where do users double-check the system? Where do they wait? Where do they copy data into spreadsheets? Where do support tickets repeat? Where is trust already broken?
Answering those questions helps engineering teams modernize with less disruption. The goal is not to preserve every old behavior. The goal is to understand why those behaviors exist before replacing them.
That approach makes modernization more practical and less risky. It also prevents teams from spending months rebuilding software only to reproduce the same friction in a newer interface.
Karumuru believes that technical modernization should be paired with operational understanding. A system may need a new architecture, but the migration path has to respect how people currently get their work done. If the new system removes a workaround without solving the reason the workaround existed, the user will simply create a new workaround.
This is one reason phased modernization can be more effective than dramatic rewrites. It allows teams to isolate high-value areas, improve observability, introduce new capabilities gradually, and validate that the changes are actually reducing friction.
For Karumuru, the goal is not modernization for its own sake. The goal is to make systems more reliable, more scalable, and easier to trust without creating unnecessary disruption for the people depending on them.
Automation should feel like relief, not replacement
Automation can create anxiety when employees believe it is being introduced to replace them or monitor them more aggressively. Karumuru believes that reaction is understandable, especially when automation is rolled out without context.
“When employees hear the word automation, they often hear, ‘Someone is trying to replace me,’” he says.
His view is that automation should be positioned and designed around relief. It should remove tedious, repetitive, error-prone work so people can spend more time on decisions, service, analysis, and human interaction.
“If we build automation without their input, it feels imposed,” Karumuru says.
That input matters. The people closest to the work usually know which tasks are frustrating, repetitive, or risky. They also know where judgment is still required. Involving them helps ensure automation supports the work instead of flattening it.
Governance is also essential. Low-code tools, AI features, and automated workflows can be useful, but without visibility, ownership, and controls, they can create new risks. Karumuru believes automation needs monitoring, auditability, security, and clear boundaries to be trusted.
Done well, automation does not remove humanity from work. It gives people time back.
Karumuru also sees automation as a way to improve consistency. Many manual processes are not only time-consuming, but also inconsistent. Different people may handle the same exception differently. Different teams may maintain different spreadsheets. Different locations may develop different habits for solving the same problem.
Automation can help standardize the repeatable parts of the process while preserving human judgment where it matters. The key is to make the logic visible enough that people understand what the system is doing and why.
Without that transparency, automation can create resistance. Users may ignore the recommendation, duplicate the work manually, or escalate issues because they do not trust the automated path. With the right design and governance, automation can become a source of confidence instead of concern.
Recognition algorithms must separate performance from opportunity
Karumuru also applies this practical thinking to gamified rewards and recognition systems. His view is that recognition technology can help workforce-heavy organizations, but only if the underlying model is fair and transparent.
“One of the most important design principles is to separate actual performance from opportunity to perform,” he says.
This is a critical distinction. Employees do not all have the same schedule, availability, role, or opportunity to earn points. A recognition model that only counts raw totals may unintentionally favor people who work more shifts or have more chances to participate.
Ratio-based models can help address that imbalance by comparing actual performance against a realistic opportunity. That makes fairness more measurable and less subjective.
“A recognition platform should never feel like a black box,” Karumuru says.
For employees to trust the system, they need to understand how recognition is earned. For managers to trust it, the data has to be accurate. For the business to trust it, the model has to be configurable, auditable, and aligned with the behaviors the organization wants to encourage.
Recognition works best when it feels consistent and fair. Without that, even a well-intended platform can create frustration.
Karumuru believes this is one of the most important lessons in applying software to culture. Human values such as fairness, appreciation, and motivation cannot be treated as vague slogans inside the product. They have to be translated into clear rules, measurable signals, and transparent calculations.
That does not mean every part of the workplace should be gamified. It means that when recognition is digitized, the system must be designed carefully. It should reinforce meaningful behaviors, avoid obvious bias, and provide enough clarity that employees do not feel manipulated by the platform.
For workforce-heavy industries, this matters because recognition often happens inconsistently. Some managers are naturally good at it. Others are overloaded and forget. Some employees are visible because of their role or schedule, while others contribute quietly. A well-designed recognition platform can help make appreciation more consistent, but only if the underlying algorithm respects fairness from the beginning.
DORA metrics and human impact belong in the same conversation
Karumuru strongly believes in engineering metrics such as deployment frequency, lead time, change failure rate, and mean time to recovery. But he does not see them as isolated technology measurements.
“If the platform is unstable, slow to change, difficult to release, or painful to recover, then the user experience will suffer no matter how good the product vision is,” he says.
For him, DORA metrics matter because they influence business outcomes. Faster recovery means less operational disruption. Lower change failure rates mean fewer avoidable incidents. Better deployment practices mean teams can deliver value more predictably.
“I do not see DORA metrics as traditional engineering metrics that sit on the side,” Karumuru says.
He believes they should be connected with usability signals, adoption trends, support patterns, and customer impact. A team may ship quickly, but if users are not adopting the feature or support tickets are rising, the system is not truly improving.
The best engineering organizations measure both stability and usefulness. They care about how software is built, but also whether it is making work better.
This is especially important in enterprise systems where product vision can be undermined by poor delivery reliability. A feature may be well designed, but if releases are unpredictable, defects are frequent, or recovery takes too long, user trust erodes.
Karumuru believes this is why engineering excellence has to be connected to human impact. Delivery metrics are not just internal scorecards. They are part of the product experience. Every avoidable incident, failed release, or slow recovery can create downstream work for clients, support teams, managers, and employees.
By looking at DORA metrics alongside adoption and support data, engineering leaders can get a more complete picture. They can see not only whether teams are moving faster, but whether that speed is improving outcomes.
From systems of control to systems of context
Many enterprise workforce systems were originally designed around compliance, tracking, and managerial oversight. Those capabilities still matter, but Karumuru believes the next major shift is toward systems that provide context and support.
“The next major shift is moving from systems of control to systems of context and support,” he says.
That could mean helping managers identify fatigue risk, schedule volatility, overtime patterns, or operational pressure before they turn into larger problems. It could mean surfacing guidance earlier instead of waiting for managers to hunt through reports after the fact.
But Karumuru is careful about the line between support and surveillance.
“Employee well-being should not become another surveillance model disguised as innovation,” he says.
The future of workforce technology, in his view, depends on responsible design. Systems should help managers make more humane and balanced decisions, not reduce employees to a set of monitored signals.
That requires explainability, governance, security, and a clear understanding of the human impact behind every technical decision.
Karumuru believes this shift will require a different mindset from engineering and product leaders. It is not enough to collect more data or produce more dashboards. The value will come from turning the right signals into useful context at the right time.
A manager does not need endless metrics during a busy shift. They need clear guidance on what needs attention. An employee does not need a system that constantly measures them without explanation. They need a system that supports fairer decisions and more consistent recognition.
The next generation of enterprise software will have to balance operational intelligence with trust. It will need to be proactive without being intrusive, intelligent without being opaque, and efficient without becoming dehumanizing.
Architecture is no longer invisible
The continuous evolution of enterprise software will depend on leaders who can connect architecture, usability, AI, automation, and workplace culture without treating them as separate conversations.
Karumuru’s central argument is that architecture is no longer invisible. In workforce-heavy environments, it shows up in how much friction people feel, how much trust they have in the system, and how much time they spend fighting technology instead of using it.
The next generation of enterprise platforms will not be judged only by how much functionality they provide. They will be judged by how clearly, they guide decisions, how reliably they connect systems, how fairly they recognize people, and how much pressure they remove from the workday.
That is where Karumuru believes engineering leaders can have the greatest impact: not by chasing technology for its own sake, but by building systems that understand the real world they are meant to serve.
In that world, architecture becomes more than infrastructure. It becomes a practical expression of how much an organization understands its users. A reliable integration, a clear alert, a fair recognition model, a faster recovery process, and a simplified workflow may all seem like separate improvements. Together, they shape whether people experience software as a burden or as support.
Karumuru’s perspective is grounded in a simple but important idea: enterprise software should reduce pressure, not transfer it. It should take the complexity that would otherwise land on the user and handle it through better design, better data, better architecture, and better engineering discipline.
That may be the real standard for the next generation of workforce technology. Not whether it looks modern. Not whether it uses the newest technology. But whether it helps people do difficult work with more clarity, confidence, and trust.
:::tip
This story was distributed as a release by Jon Stojan under HackerNoon’s Business Blogging Program.
:::