How Cam Stevens Thinks About Human Judgment Before Safety Technology Scales

Episode 15 of the Headline Podcast, published on March 18, 2026, features Cam Stevens discussing safe technology adoption, prediction hype, and technology-driven psychosocial risk. His central argument is that leaders should protect human judgment by defining the problem before they buy, scale, or celebrate a safety tool.

Cam Stevens said, “If we're very clear on the problem to solve, then a technology catalog is excellent. If we're not clear on the problem to solve, a technology catalog is very dangerous.” That distinction gives safety leaders a practical filter for the next digital proposal, because the question is not whether a system is impressive, but whether it improves a decision that matters.

What problem should safety technology solve?

Safety technology should solve one defined operating problem whose exposure, user, decision, and evidence are visible. A leader who cannot describe those four elements before adoption is not ready to evaluate the tool, because the organization will measure installation, logins, or alerts instead of a change in risk.

The first conversation should therefore happen without a vendor. Ask what condition is difficult to see, which decision arrives too late, and what barrier is unavailable when the work changes. The answer might concern a delayed escalation, a weak handover, an unreliable critical-control check, or a reporting route that workers do not trust.

Andreza Araujo's work on culture and leadership makes this distinction important. In Safety Culture: From Theory to Practice, the useful question is not whether a safety intention has been declared, but whether the organization has translated it into routines that people can use under pressure. Technology is one possible routine. It is not a substitute for one.

Four questions before purchase: What problem is visible, who decides, what evidence is trusted, and what changes if the tool is unavailable?

Why does prediction hype weaken safety leadership?

Prediction hype weakens safety leadership when a probability is treated as a fact and an alert is treated as a decision. A prediction can prioritize attention, but it cannot remove uncertainty, explain every cause, or carry accountability for the action that follows.

Cam's point matters because safety teams are often asked to make a new tool sound certain before the operating model is ready. A red score may be presented as danger, although it may only indicate that a pattern resembles earlier data. A green score may reassure a supervisor even though the physical condition has changed outside the model's inputs.

Leaders should ask five questions. What exactly is being predicted? Which data supports the inference? How often can the alert be wrong? Who receives it? What action is authorized? Those questions turn a persuasive demonstration into a governance review.

The NIOSH hierarchy of controls explains why a digital alert should not be mistaken for a stronger control simply because it is new. If the exposure can be eliminated, engineered out, or physically separated, an alert should support that decision rather than become the organization's preferred response to a hazard that remains in place.

What evidence should leaders demand before scaling a tool?

Leaders should demand evidence that connects the technology to a changed condition, a faster decision, or a stronger barrier. A 30-day pilot is useful when it tests the operating chain rather than collecting flattering screenshots, and when the review includes false alerts, missed signals, user effort, and verified follow-through.

Cam's problem-first logic supports a simple comparison. The left side describes a technology program that is busy but unproven. The right side describes a decision system that has earned the right to scale.

OSHA describes safety management programs as systems that depend on leadership, worker participation, hazard identification, prevention, and continuous improvement. A digital tool should be reviewed against those operating elements, because adoption without ownership can produce another layer of documentation rather than a safer decision.

Use five evidence checks: signal quality, response time, false-alert burden, control ownership, and verified field effect.

How should leaders govern voice and safety data?

Voice and safety data improve decisions when workers can report relevant conditions, understand what is collected, and see a credible response after they speak. The system needs three visible commitments: limited access, clear purpose, and a named owner who can convert a report into a control decision.

Cam Stevens described voice technology as a potential data source, which is valuable because workers may notice a weak signal before a formal indicator changes. The benefit disappears when reporting becomes surveillance, when language is misunderstood, or when submissions enter a queue with no response standard.

A leader can test the route with one hypothetical report and one real low-consequence concern. Track how many people touch the report, how many days pass before an owner responds, and whether the final correction is verified. A system that records 20 concerns but closes none with evidence has increased visibility without increasing trust.

That is where Andreza Araujo's emphasis on observable culture is useful. A process belongs to the culture only when people can rely on it during a difficult decision. The interface, microphone, or analytics layer matters less than the response that follows a worker's signal.

Where can technology create psychosocial risk?

Technology can create psychosocial risk when it changes workload, autonomy, role clarity, social interaction, or recovery time while the organization describes the change as visibility. A system that sends 20 alerts during a shift may improve detection, yet still weaken safety if the supervisor cannot distinguish two actionable signals from 18 interruptions.

Cam said, “The changing shift in risk profile will be overwhelmingly psychosocial, driven by technology usage in our organizations.” The warning is not an argument against adoption. It is a demand that leaders examine the work design created by the tool.

Review the new process at three levels. At the individual level, ask whether attention is fragmented and whether the worker can recover. At the team level, ask whether alerts create conflict about who must respond. At the leadership level, ask whether the system encourages constant availability or makes responsibility less clear.

ISO 45001 specifies a management-system approach in which organizations establish processes, responsibilities, and operational controls. The technology review should fit that logic by naming the owner, the escalation route, the competence required, and the evidence that the new process does not create a second hazard.

Which decisions should remain human?

Human judgment should remain explicit when a decision depends on context, competing evidence, ethical accountability, or authority to stop work. Technology can organize information and identify patterns, but it should not silently decide whether an exposure is acceptable or whether a person must continue under uncertainty.

Cam Stevens said, “We can elevate the human experience with technology, but there are certainly times when technology should absolutely not be used.” The boundary is a leadership responsibility. A camera may detect a missing guard, but it cannot understand every constraint that shaped the task. A model may rank an inspection, but it cannot own the moral decision to leave people exposed.

Define three non-delegable judgments before the pilot starts. One may be confirmation that an isolation is trustworthy. Another may be the decision to stop work when conditions diverge from the plan. A third may be whether a reported concern requires immediate escalation even when the data is incomplete.

Antifragile Leadership applies a related principle to safety leadership, because a strong leader uses uncertainty to improve the decision system rather than hiding uncertainty behind a more confident interface. That is why the best technology governance makes the limits of the tool visible.

Recommendation

Run a 30-day technology review with one defined problem, one operating owner, one technology owner, and five evidence checks. Scale only when the tool changes a real decision without creating unacceptable workload, surveillance pressure, role confusion, or dependence on a signal that can fail.

On day 1, write the problem in one sentence and name the decision that should improve. By day 7, observe the work without the tool's dashboard and record the conditions that the system cannot see. By day 14, compare alerts with field evidence and classify false positives, missed signals, and delayed responses.

By day 21, ask the users what the process makes harder, what it makes easier, and which responsibility has become unclear. On day 30, decide whether to scale, redesign, or stop. The decision should include the operating owner, because a technology team cannot carry a control that maintenance, operations, engineering, or procurement can weaken.

Andreza Araujo has spent more than 25 years connecting safety leadership with the decisions that shape work, and her books return to the same practical test: culture is visible in what people do when the pressure is real. A technology program deserves support when it strengthens that behavior, not when it merely produces more data.

Listen to the full conversation with Cam Stevens on the Headline Podcast. The episode is a useful starting point for any leader deciding whether a new safety technology will improve human judgment or quietly replace it.

Conclusion: safety technology earns the right to scale only when leaders can name the problem, test the signal, protect human judgment, and verify that the new process improves work without creating a new psychosocial burden.