5 Insights from Episode 15 with Cam Stevens

Episode 15 of the Headline Podcast, published on March 18, 2026, features Cam Stevens, CEO of PKG and a safety technologist, discussing how technology changes the problems safety leaders need to solve.

His central thesis is that technology improves safety only when leaders define the problem first, preserve human judgment, and examine the psychosocial consequences created by the tool itself.

1. Start with the problem, not the technology catalogue

A safety technology decision should begin with a defined exposure, decision, or control weakness. The catalogue comes later, because a tool cannot be evaluated until leaders know what reliable improvement would look like in the work.

Cam Stevens puts the risk plainly: “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 distinction matters because technology creates its own momentum. A demonstration can be impressive, a dashboard can look precise, and an executive sponsor can become attached to the promise before anyone has described the operational problem in observable terms.

A leader should therefore write the problem in one sentence before approving a pilot. The statement should name the work, the exposure, the current control, and the decision that remains unreliable. “We need better safety data” is too broad. “Supervisors receive high-consequence equipment alarms without a consistent response owner” is specific enough to test.

This discipline also protects the workforce from carrying the burden of a vague experiment. When the problem is unclear, workers become the source of data, the tester of the interface, and the person blamed when adoption does not produce the promised result.

2. Treat psychosocial risk as a technology-design question

Technology changes psychosocial risk when it changes how much control people have, how closely they are watched, how much work they must absorb, and whether they can still use professional judgment. The risk review belongs in the design phase, not after deployment.

Cam Stevens describes the direction of travel directly: “The changing shift in risk profile will be overwhelmingly psychosocial, driven by technology usage in our organizations.” That statement does not mean that physical hazards disappear. It means that the technology layer can move strain into autonomy, attention, responsibility, trust, and work organization.

A new system may reduce manual entry while increasing alerts. It may support a decision while making the worker feel that every action is monitored. It may give managers more information while leaving the frontline team with less authority to interpret what the system reports.

ISO 45003:2021 provides a useful frame because psychosocial risk is connected to work design, demands, control, support, relationships, role, and change. A technology review should ask how those conditions move across the six dimensions rather than treating the tool as a neutral object.

The most important question is not whether employees like the interface. It is whether the technology leaves them with enough clarity, authority, recovery, and support to perform the work safely when conditions do not match the model.

3. Use voice technology to reduce friction, not replace judgment

Voice tools can make reporting and communication easier when the problem is friction, delay, or poor access to a system. They become unsafe when an organization treats recorded language as a complete interpretation of risk or uses it to remove the people who understand the context.

Voice technology is attractive because it can fit the work more naturally than a form that requires a worker to stop, find a device, remember a code, and translate a complex concern into a narrow field. That reduction in friction can improve the quality and timeliness of signals.

The signal still needs a human pathway. Leaders must decide who reviews it, how quickly the person responds, what information is retained, and how the worker learns what happened after speaking. A voice channel that receives concerns without visible follow-through can create a new form of silence, because people learn that speaking produces data but not action.

Privacy also belongs in the control design. Workers need to understand whether the system records a phrase, an identity, a location, a pattern, or all four. If the technology changes the perceived cost of speaking, the organization may collect more words while receiving less honest information.

Use the same three tests for every voice pilot. First, does it make the relevant concern easier to express? Second, does the organization respond with a named owner? Third, can the worker challenge the interpretation without becoming the problem?

4. Compare the promise with the human consequence

A technology is not ready because it performs its technical function. It is ready when the operational benefit is greater than the new burden created for workers, supervisors, and decision owners.

The table exposes a common mistake. Leaders measure the benefit in the language of the vendor, then measure the human consequence only after complaints appear. The stronger sequence is to define both sides before the pilot begins.

Andreza Araujo's safety-culture work is useful here because visible compliance is not the same as a reliable operating condition. A system can be installed, used, and reported as successful while the people closest to the work carry more uncertainty than before.

That is why the adoption review should include the person who uses the tool, the person who responds to its output, and the person whose performance may be judged by it. Their answers will rarely be identical, and the differences are part of the risk assessment.

5. Decide when technology should not be used

The most mature technology strategy includes a clear refusal rule. Leaders should not use a tool when it cannot address a defined problem, when no one owns the response, or when automation removes judgment that the work still requires.

Cam Stevens states the boundary without ambiguity: “We can elevate the human experience with technology, but there are certainly times when technology should absolutely not be used.” That position resists the assumption that every manual activity is waste or that every human decision is an inefficiency waiting to be automated.

A refusal rule is especially important when the tool changes trust. Facial recognition, continuous location tracking, automated productivity scoring, and opaque predictive models may produce data while making people less willing to report, ask for help, or explain a deviation.

Technology should also be rejected when the organization cannot maintain the process around it. A sensor that creates ten alerts but no response capacity does not strengthen control. It adds work and creates the impression that the risk is being managed because the screen is active.

Before deployment, write down the conditions that would stop the pilot. Include privacy failure, unowned signals, repeated false alarms, reduced reporting, new work outside the original role, and any situation in which the tool is used as a disciplinary shortcut.

Recommendation

Use Cam Stevens's five-part test before approving a safety technology. Define the problem, map the psychosocial effects, design the human response, compare benefit with burden, and state the conditions under which the organization will refuse or stop using the tool.

The practical next step is a 30-minute review with the EHS leader, operations owner, worker representative, technology owner, and the person who will receive the signal. Ask each participant to answer the same five questions in writing. Differences should be resolved before a pilot, not hidden inside a launch meeting.

For the Headline audience, the broader lesson is straightforward. Technology is not a substitute for leadership judgment. It is a design choice that can strengthen control or redistribute risk, depending on whether leaders stay accountable for the conditions their tools create.

Read the companion discussion on when safety technology should not be used, then compare it with Corrie Pitzer's view of risk competence before metrics can be trusted and the practical psychosocial-risk register guide.

Listen to the full conversation and consider which technology decision in your organization needs a problem statement before it needs a purchase order.