The Human Dignity in Automation

The Human Dignity in Automation

There is a version of the automation conversation that is genuinely worth having, and a version that is mostly noise. The noise version is the one that dominates most business media: will AI replace this category of worker, will robots eliminate these jobs, is your profession safe. These questions are real enough in aggregate, but they are not the most useful frame for a business leader trying to make good decisions about how to deploy automation in the specific organization they are responsible for running. 

The more useful question is not whether to automate. It is whether the way you automate respects the dignity of the people who remain in the process. 

This is not a soft question dressed up in business language. It has direct operational consequences. Organizations that automate in ways that diminish the people in the process tend to produce brittle outcomes — they get the efficiency gains they were looking for in the short term, and they pay for them in turnover, in institutional knowledge loss, in the slow degradation of the judgment and relationship quality that cannot be replaced by the tools that were supposed to make everything faster. Organizations that automate in ways that genuinely serve the people in the process tend to retain the things that cannot be automated: trust, depth, the human judgment that the organization actually depends on even when it is not fully aware that it does. 

The distinction between the two is not primarily technological. The same automation tools can be deployed either way. The distinction is in the intention and the architecture behind the deployment — whether the design question was “how do we make this process more efficient” or “how do we give these people back time they are currently spending on work that does not use them well.” 

What Dignity Looks Like in Practice 

The clearest way to see the difference between efficiency-oriented and dignity-oriented automation is to look at what the person inside the process experiences after the automation is in place. 

In the efficiency-oriented version, automation is designed to extract maximum output from minimum labor. Work gets decomposed into tasks, tasks get evaluated for automability, and the ones that can be handled by the system get handed to the system. The people who remain are left with what could not be automated — which frequently means the most difficult, most ambiguous, most emotionally demanding work, stripped of the context and the variety that made it bearable. The message the design sends, whether intentional or not, is: your value to this organization is what remains after we have removed everything we could. 

In the dignity-oriented version, automation is designed to remove what the people in the process find most burdensome without removing what makes the work meaningful. This requires actually understanding what makes the work meaningful to the people doing it, which requires asking them rather than assuming. The frequently surprising finding when organizations do this honestly is that what people find burdensome is not always the same as what is most automatable — and the automation decisions that produce the best outcomes for both quality and retention are the ones designed around the former rather than the latter. 

The Drudgery Question 

The practical diagnostic for whether an automation initiative is dignity-oriented or efficiency-oriented is the drudgery question: are we removing the parts of this work that nobody would choose to spend time on if they had a choice, or are we removing the parts that happen to be most replaceable by software? 

These are not the same thing. A skilled IT professional’s day might include a significant amount of ticket triage, data entry, and low-complexity support requests — genuinely burdensome tasks that nobody would miss. It might also include a significant amount of vendor management, infrastructure documentation, and compliance reporting that is technically straightforward but carries important relational context. Both categories might be candidates for automation based on complexity. Only the first is a candidate based on what the person actually finds grinding and joyless. 

The organizations that have gotten this right are the ones that understood early that the measure of successful automation is not the percentage of tasks that have been handed to the system. It is whether the people who remain in the process are spending more of their time on the work that uses their judgment, their relationships, and their accumulated expertise — and less of their time on the work that neither requires nor develops any of those things. Efficiency that is a byproduct of that design is sustainable. Efficiency that comes at the expense of it tends to cost more, eventually, than it saved. 

The IT Context 

In technology and security environments specifically, the distinction between these two approaches has consequences that go beyond morale and retention, into the quality of the security posture itself. 

When automation is deployed in ways that thin the human layer in a security operation — reducing analyst involvement on the premise that the tools handle most of the detection — the short-term efficiency gain is real. Fewer people processing fewer alerts. Lower cost per event reviewed. When this is paired with the confident output of the detection tools, it can look like an unambiguous improvement. 

What it actually produces, over time, is the erosion of the human judgment capability that the security operation depends on when the tools surface something genuinely unusual. The analysts who are not being challenged to interpret, decide, and be accountable for the outcome of their interpretation are not developing the expertise that makes them valuable in the high-stakes situations that automation cannot resolve. The efficiency was purchased at the cost of the human capacity that the efficiency was supposed to be supporting. 

Dignity-oriented automation in a security context looks different. It removes the repetitive, low-judgment work that consumes analyst time without developing their expertise — the alert fatigue that comes from reviewing hundreds of low-confidence signals and finding nothing actionable. It returns that time to the work that requires interpretation, contextual knowledge, and the kind of judgment that accumulates through experience rather than through processing volume. The analysts are better at their jobs because the automation took the work that was grinding them down rather than the work that was challenging them to grow. 

The Leadership Decision 

The distinction between these two orientations is ultimately a leadership decision, not a technology decision. The tools do not choose what to optimize for. The question of whether the automation is designed around the organization’s efficiency targets or around the development and dignity of the people inside the process is answered before anyone writes a line of code or configures a workflow — it is answered in how the design question is framed. 

Leaders who frame it as “how do we reduce labor cost” will make automation decisions that optimize for that target and get the predictable consequences: short-term cost reduction, medium-term turnover, and the eventual realization that the things that were automated away included some of the things the organization could not afford to lose. Leaders who frame it as “how do we give our people back the time and capacity they are currently spending on work that does not use them well” will make different decisions and get different outcomes. 

The framing is not just philosophical. It changes the consultation process before deployment, which changes which tasks get targeted. It changes the success metrics used to evaluate the automation after deployment, which changes what gets optimized over time. It changes what the people inside the process believe about their organization’s relationship to them, which changes whether they stay and whether they bring their full judgment to the work when they do. 

Technology and People, Not Technology or People 

The framing that has done the most damage in the automation conversation is the implicit either/or: technology or people, efficiency or dignity, automation or employment. This framing is bad strategy, not just bad ethics. 

The organizations performing best in complex, high-stakes environments are not the ones that have replaced human judgment with automated systems. They are the ones that have used automated systems to make human judgment more effective — by removing the cognitive load of low-value processing, by providing analysts and advisors and specialists with better information faster, by creating the space for people to do the work that actually requires a person. The technology serves the human capability. The human capability produces the outcome the organization actually needs. 

This is the version of automation that holds up over time, and it is the version that is worth building toward. Not because it is kinder, though it is. Because it produces better results, sustains the institutional knowledge that makes the organization effective, retains the people who carry that knowledge, and preserves the human judgment that automated systems cannot replicate no matter how good they get. 

The line between efficiency and dehumanization is not a bright line visible in any single decision. It is the cumulative result of many decisions about what to remove, what to protect, and who gets asked before the answer is announced. Leaders who are paying attention to which side of the line their automation decisions fall on are building something durable. Leaders who are not paying attention to it tend to find out where the line was after they have crossed it. 

What Gets Lost When the Design Is Wrong 

The costs of efficiency-oriented automation that underinvests in the dignity question tend to accumulate in the same places, regardless of industry. 

The first is institutional knowledge. The people who leave — and they tend to leave faster in organizations where the automation message has been received as “your judgment is being replaced” rather than “your burden is being reduced” — take with them contextual understanding that cannot be reconstructed from the systems they were running. The senior IT professional who understood why a particular network configuration existed, what the historical edge cases looked like, and how the organization’s environment had evolved over a decade carries knowledge that no documentation fully captures. When that person leaves because the environment has been made unrewarding, the knowledge leaves with them. The automated system that replaced some of their work does not know what they knew. It cannot. 

The second is judgment quality. This is harder to see in the short term because it does not produce an immediate crisis — it produces a gradual degradation in the sophistication and appropriateness of decisions made by the people who remain. Expertise develops through challenge. Professionals who are consistently given work that requires interpretation, contextual judgment, and accountability for outcomes develop those capacities over time. Professionals who are given work that has been progressively simplified by automation — the messy and ambiguous stripped out and handed to the system, the residue left for the human — develop a narrower and narrower range of the expertise the organization actually needs from them. 

The third is trust. Not the abstract kind, but the operational kind: the degree to which people inside the organization believe that the organization has their genuine interests in mind when it makes decisions about their work. Organizations that lose this — where the perception has formed that automation initiatives are primarily about cost reduction dressed in the language of empowerment — find that the people who remain become protective of their scope, less likely to surface problems that might be used to justify further automation, less willing to invest in development that could be seen as transferable to the system rather than exclusive to them. The honest information flow that organizations need to function well degrades. This is not visible on an efficiency dashboard. It shows up in the quality of the decisions that get made with incomplete information, and in the incidents that the organization discovered too late because nobody wanted to be the one who raised the issue. 

The Consultation That Changes the Answer 

There is a practical step that consistently separates organizations that deploy automation well from those that do not: they ask the people inside the process what they actually find burdensome before designing the solution. 

This seems obvious stated plainly. It is not standard practice. The more common approach is to map the process, identify the most time-consuming or lowest-complexity tasks, and design the automation around what the analysis surfaces. This produces technically correct answers to the wrong question. The question is not which tasks take the most time. It is which tasks are most grinding, most meaningless, most draining to the people doing them — and whether the candidates for automation are in that category or in the category of work that is challenging and developing and worth doing. 

The conversation that changes the answer often reveals something counterintuitive: that what people find most burdensome is not always the work that looks most automatable from the outside. A customer-facing professional might find that the automated scheduling tool produces more burden than it removes, because the edge cases it cannot handle create exceptions that require more judgment than the original process did. An analyst might find that the automated alert dashboard creates fatigue faster than manual review did, because the volume and format of the summarized output is less legible than the raw data they had developed instincts for reading. These are not arguments against automation. They are arguments for asking the question before designing the answer. 

The organizations where this conversation happens are also the organizations where the automation, once deployed, tends to stick. People accept and use tools that were designed around what they actually find difficult. They route around or quietly ignore tools that were designed around what looked most replaceable from a distance. The consultation is not just a dignity practice. It is a deployment-effectiveness practice. The design that asks the right question is the design that produces the outcome the organization actually wanted from the investment. 

Tom Glover is Chief Revenue Officer at Responsive Technology Partners, specializing in cybersecurity and risk management. With over 35 years of experience helping organizations navigate the complex intersection of technology and risk, Tom provides practical insights for business leaders facing today’s security challenges.