Cam Stevens on Safety Technology Before Adoption

Episode 15 of Headline Podcast, published on March 18, 2026, features Cam Stevens discussing how safety leaders should decide whether technology belongs in a control strategy. His central argument is that a technology catalog is useful only after the organization has defined the problem it needs to solve and the evidence that would show improvement.

That sequence matters because the wrong tool does more than waste a budget. It can create false confidence, increase surveillance pressure, and move attention away from a weak work design that technology cannot repair. Cam Stevens put the point directly on the show: 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.

Why the problem must come before the product

Technology decisions often begin with a demonstration, a vendor promise, or a new capability that feels too useful to ignore. A camera detects a condition, a wearable measures exposure, or an artificial intelligence tool predicts a pattern. The demonstration is real, yet it does not answer the first management question, which is what operational decision should become better because the tool exists.

A leader who starts with the product may end up collecting data without changing a control. The team can produce a new dashboard, but the supervisor still lacks authority to stop the task, maintenance still receives late information, and workers still cannot explain what happens after an alert. The gap is not technical. It is a decision-design failure.

Cam Stevens's problem-first position is consistent with the risk-management logic in ISO 45001, which defines a management system for controlling occupational health and safety risks. A tool can support that system, but it cannot replace the organization’s process for identifying hazards, assigning responsibility, consulting workers, and checking whether controls remain effective.

What a useful technology decision should name

Before procurement, write one sentence that describes the operational problem in observable terms. For example, the issue may be that a critical control is not verified during a handover, that a mobile crew receives warnings too late, or that supervisors cannot see recurring deviations across four work fronts.

The sentence should identify the affected work, the decision that is currently weak, and the consequence of leaving it weak. It should not describe a product category. “We need computer vision” is a solution label. “We cannot verify whether exclusion zones remain intact during vehicle movements on the night shift” is a problem statement that can be tested.

Use a four-part record before the first vendor meeting. State the problem, name the decision owner, define the evidence needed, and set a review date. A 30-day review can test whether the tool changed a decision quickly, while a 90-day review can test whether the improvement survived normal production pressure.

The record also protects the organization from a familiar procurement error. When no one can say who owns the decision, the technology becomes an information project rather than a safety control. The data may be accurate, although the response remains optional.

Why prediction is not the same as prevention

Prediction language can make a safety product sound more powerful than the operating system around it. A model may identify a pattern, rank a location, or flag an unusual sequence, but the output still needs a person who understands the context and has authority to act.

Cam Stevens warned against prediction hype because a signal is not automatically a control. If a model produces 100 alerts and the team has capacity to investigate only 10, the organization needs a prioritization rule before it needs more sensitivity. If the system flags a risk but does not identify the available intervention, it may increase concern without improving protection.

NIOSH describes the hierarchy of controls as a way to select and prioritize protective measures. That sequence keeps the decision anchored in elimination, substitution, engineering, administrative controls, and personal protective equipment. Digital monitoring can support several layers, but a notification is not equivalent to removing the hazard.

The practical test is simple. Ask what happens during the first 10 minutes after an alert, who receives it, what decision they can make, and what record proves that the decision occurred. If those answers are missing, the organization is buying detection without a response pathway.

How technology changes psychosocial risk

Safety technology is often presented as neutral, although workers experience it through rules about visibility, pace, evaluation, and trust. A system that records every movement may improve hazard detection while also making people feel that normal judgment is being treated as suspicious behavior.

Cam Stevens identified technology-driven psychosocial risk as a changing part of the safety profile. That point deserves attention because a tool can create pressure even when its technical function works as designed. A wearable that measures fatigue, for instance, may help a worker request recovery, or it may become an unexplained score used to challenge the worker’s reliability.

Leaders should therefore assess at least five human consequences before deployment: what is collected, who can see it, how long it is retained, how it affects evaluation, and how a worker can challenge an interpretation. The assessment should include a worker representative and the supervisor who will receive the signal, not only the information-technology team. OSHA explains that safety-management programs work when management leadership, worker participation, and hazard prevention operate together.

Cam Stevens also said, The changing shift in risk profile will be overwhelmingly psychosocial, driven by technology usage in our organizations. The statement does not mean technology is harmful by definition. It means that the human conditions around the tool belong inside the risk decision rather than in a later communications plan.

Technology choice versus control choice

The comparison below keeps the decision focused on the control function rather than on novelty. It also clarifies where a digital tool may help and where a different intervention should come first.

The control-first column does not reject technology. It gives the tool a narrower and more defensible job. That distinction is important when a leader compares proposals that use similar words but would produce very different consequences in the field.

How EHS leaders can test adoption before scaling

A pilot should be small enough to observe and important enough to matter. Choose one work process, one decision owner, one defined consequence, and one evidence route. A four-week pilot is long enough to reveal whether the tool fits the work rhythm, although it is not long enough to prove that every risk has been controlled.

Use the first week to confirm the problem statement and the data boundary. Use weeks 2 and 3 to observe the response to real signals, including false positives and missed context. Use week 4 to compare the original decision process with the operated process and to ask workers whether the tool changed what they could do.

Keep the success criteria visible. A useful pilot may show that supervisors respond 15 minutes earlier, that a handover includes 3 required verification points, or that a critical-control deviation reaches the owner before the task continues. Those numbers are local acceptance criteria, not universal performance claims, and they should be agreed before the pilot starts.

For a related way to make uncertainty explicit, compare the pilot with the risk register, risk appetite, and decision log. The tool should strengthen the decision record rather than create a second system that no one reconciles.

Recommendation

Headline Podcast listeners should treat safety technology as a control decision, not as a procurement trend. Start with the problem that a worker or supervisor cannot currently manage well, identify the person who can change the condition, and define what evidence would justify continuing after 30 days and 90 days.

Then test the human consequences before scaling. Ask whether the tool makes risk information easier to use, whether it increases fear or surveillance, and whether the people closest to the work can challenge a misleading signal. If the answer is unclear, the correct next step is not a larger rollout. It is a better decision design.

Cam Stevens's argument is useful because it preserves a basic discipline that technology marketing can obscure. A tool earns its place when it improves a specific decision, strengthens a control, and leaves workers with more usable information rather than more unexplained monitoring.

For a second perspective on evidence quality before metrics can be trusted, read how Corrie Pitzer frames risk competence. To examine the burden of proof in a high-consequence decision, see Rodney Rocha's view of risk decisions.

Listen to the full conversation with Cam Stevens on Headline Podcast, and use the episode's problem-first question before approving the next safety technology purchase.