6 Insights from Episode 15 with Cam Stevens on Technology Decisions in Safety

Episode 15 of Headline Podcast, published on March 18, 2026, features Cam Stevens, safety technologist and CEO of PKG. He argued that safety leaders should define the problem before they select a technology, because adoption without a clear purpose can change the risk profile instead of improving it.

That argument matters to every EHS manager who has been asked to approve a dashboard, wearable, voice tool, camera system, or predictive platform before anyone has agreed on the decision it should improve. Andreza Araujo has made the same leadership distinction across more than 250 cultural transformation projects. A tool is not a safety strategy, and a new data stream is not automatically a better control.

1. Define the Problem Before You Open the Technology Catalog

Cam Stevens's first insight is a governance rule. The organization should name the operational problem, the affected people, and the decision that currently fails before it reviews products. This protects leaders from confusing novelty with prevention, which matters when a vendor can describe ten capabilities before the site has described one unresolved exposure.

On the episode, 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." The quote leaves room for technology while rejecting technology-led diagnosis.

An EHS manager can make the problem concrete by completing one sentence. We need to improve the decision about... The answer might concern contractor readiness, exposure verification, fatigue escalation, emergency communication, or worker voice. If the sentence ends with "because the market has a new platform," the organization is not ready to buy.

This approach connects with Andreza Araujo's Safety Culture: From Theory to Practice, whose practical lesson is that systems become credible when daily decisions support the stated standard. Technology deserves approval only when it strengthens that connection.

2. Separate a Signal From a Metric

A signal can prompt a question without becoming a target. That distinction prevents leaders from turning every measurable trace into a performance score, which can produce gaming, silence, or a false sense of control. The right question is whether the data improves a defined decision without damaging the work around it.

Cam Stevens discussed voice technology as a possible data source, yet the episode does not support the easy conclusion that more voice data equals better safety. A recorded concern may reveal friction in a process, but it does not explain whether the barrier is competence, workload, work design, supervision, equipment condition, or trust.

A technology review should state four things before the first dashboard is built. It should define the signal, identify the decision owner, describe the follow-up action, and name the limit of interpretation. Without those fields, a leading indicator can become a decorative number that receives attention without changing control quality.

Andreza Araujo's work on safety indicators returns to this problem. A measure has value when it changes a conversation at the right level, not when it makes a report look more sophisticated. Leaders who cannot explain the action behind a number should not elevate that number to executive status.

3. Test Whether the Tool Changes the Human Experience

Technology enters a social system, not an empty workflow. It changes how workers are watched, how supervisors respond, how quickly work is expected to move, and whether people retain the judgment needed to notice weak signals. A tool is ready only when leaders have examined the human experience it will create in ordinary work, not only the control it promises in a demonstration.

Cam Stevens said, "We can elevate the human experience with technology, but there are certainly times when technology should absolutely not be used." That sentence gives EHS leaders permission to treat restraint as a professional decision rather than a failure to innovate.

The review should ask whether the system reduces unnecessary effort, gives workers a clearer route to raise a concern, or removes repetitive exposure. It should also ask whether it increases monitoring, interrupts attention, reduces discretion, or pressures people to work at the pace of an algorithm. These effects often appear after implementation, when the original business case has already been approved.

Cam Stevens's earlier episode companion on changing risk profiles develops the same concern from another direction. This article shifts the focus to leadership choice, because the most important control may be deciding what the tool must not change.

4. Treat Psychosocial Risk as a Design Question

Psychosocial risk is not an optional side review for technology projects. A new system can alter workload, autonomy, visibility, recovery time, and the meaning of performance, which means the safety leader must test the work design before accepting the technical design. The device may be accurate while the job becomes less sustainable.

The episode identifies technology usage as a driver of a changing risk profile. That does not mean every digital tool causes harm. It means leaders should examine the pathway between adoption and experience. A camera may improve a critical control inspection while making workers feel permanently observed. A voice assistant may shorten reporting while adding another interruption during a high-risk task.

ISO 45003 gives organizations a useful language for this review because it connects psychosocial risks with organizational conditions. Ask which part of work changes, who absorbs the change, and how the organization will know if the burden has moved rather than disappeared.

Andreza Araujo's Antifragile Leadership is relevant here because it treats pressure as something leaders must govern, not merely celebrate. A technology project that increases speed while weakening recovery or voice is not automatically resilient. It may be transferring risk to the people with the least authority to redesign the system.

5. Compare the Promise With the Operating Reality

A useful comparison separates what a technology vendor promises from what the operating system can sustain. Leaders should examine the decision, the evidence, the owner, and the worker effect before discussing return on investment. This prevents a polished product narrative from becoming the unofficial risk assessment.

The difference between the two columns is a control decision. A tool that produces data without a response owner adds administrative work, while a tool that changes behavior without a worker safeguard can create a new exposure that the original business case never measured.

Leaders can document the comparison in five fields and revisit it after one operating cycle. If the decision, evidence, ownership, worker effect, and stop condition remain clear, the project has a chance of serving the work. If any field becomes vague, the project needs review before expansion.

6. Make Technology a Shared Leadership Decision

Technology adoption should not belong to EHS alone, because the consequences cross operations, IT, HR, procurement, and frontline work. The safety leader's role is to make the risk logic visible, invite evidence from the people closest to the task, and keep the final decision connected to the condition that justified the project.

Cam Stevens's problem-first position is strongest when it becomes a shared discipline. Operations understands the work sequence, IT understands the system boundary, HR understands privacy and workload implications, procurement understands the contract, and workers understand the difference between the process on paper and the process at 2:00 a.m.

Andreza Araujo has spent more than 25 years connecting executive decisions with frontline reality across 30+ countries. The leader should not ask workers to endorse a tool after the decision has been made. The leader should invite them to define the problem while alternatives are still open.

The companion on voice data and safety metrics is useful when the project involves worker input. Collection and governance are separate decisions even when they appear in the same product proposal.

Recommendation

Before approving a safety technology project, convene one problem-definition session with the people who will operate, govern, support, and experience the change. Record the decision the organization needs to improve, the evidence that would be sufficient, the person who owns the response, the worker experience that must be protected, and the condition that would require a pause.

Then test the proposal against one ordinary shift rather than one vendor demonstration. If the tool improves the decision without weakening attention, trust, discretion, or recovery, adoption may be justified. If it creates a new burden that the project cannot measure or govern, do not hide that weakness behind more data.

That is the leadership lesson Cam Stevens brings to Episode 15. Technology is valuable when it serves a defined safety problem, and it becomes dangerous when the product leads the organization toward a problem it never chose to solve. Andreza Araujo's editorial work makes the same point from the culture side: credibility grows when leaders make the operating choice visible and keep accountability attached to the decision.

Listen to the full conversation with Cam Stevens on Headline Podcast, then use the five-field review above before your next technology approval.