How Cam Stevens Thinks About Technology-Driven Psychosocial Risk

Episode 15 of Headline Podcast, published on March 18, 2026, features Cam Stevens, safety technologist and CEO of PKG, in conversation with Andreza Araujo and Dr. Megan Tranter. His point is not that technology is bad. His point is that technology only helps when leaders define the problem first, because the wrong tool can make a weak system faster without making it safer.

That matters in psychosocial risk because software changes more than workflow. It changes monitoring pressure, trust, pace, interruption, and the social cost of speaking up. As Andreza Araujo has seen across more than 250 cultural transformation projects and 25+ years in multinational EHS, the failure is rarely the data itself. The failure is the decision discipline around what the data is supposed to change.

Why a digital rollout can become psychosocial risk

Cam Stevens does not frame technology as a neutral layer. He says, "The changing shift in risk profile will be overwhelmingly psychosocial, driven by technology usage in our organizations." That is a practical warning, not a slogan. A tool can improve speed and still leave the team more watched, more interrupted, and less willing to surface weak signals.

The main issue is not adoption volume. It is the human load created by the rollout. If a new system adds fields, alerts, checks, and rework, the organization may be collecting more data while quietly taxing attention and judgment. That is why this article sits in the psychosocial-risks category rather than in a generic technology category.

For a useful companion angle, read How Cam Stevens Thinks About Voice Technology in EHS. This piece goes one layer deeper, because the question is not only whether the tool works. The question is what the tool does to workload, trust, and decision quality after the pilot starts.

What problem-first means when the risk is human

Problem-first does not mean buying less technology. It means naming the actual failure the organization wants to fix. Cam Stevens says on the episode, "If we're very clear on the problem to solve, then a technology catalog is excellent." He also warns that if the problem is not clear, "a technology catalog is very dangerous." That distinction matters because many teams buy capability before they define the decision it must improve.

A problem-first review needs four things before a launch: the problem statement, the owner, the response clock, and the verification method. If any of those four is missing, the rollout becomes a convenience project instead of a control project. A system can reach 90 percent adoption, 80 percent completion, and 100 percent installation while still missing the one decision that would reduce exposure.

Andreza Araujo has argued in A Ilusao da Conformidade that control on paper is not the same as control in the field. In Muito Alem do Zero, the same lesson appears from another angle: a clean number can hide underreporting, fear, or simply a delay between what the dashboard sees and what the crew lives.

Where ownership breaks the signal

Cam Stevens is strongest when he shifts attention from tools to ownership. A signal only matters if someone can say what changes before the next shift and who checks that it changed. Without that, the signal ages in the queue while the task continues. That is how digital systems become busy front doors for slow decisions.

The practical test is simple. If a concern reaches the system in under 24 hours, but the field change still takes 2 weeks, then the organization has improved intake without improving control. That is a useful lesson for EHS, HR, and operations leaders who want better visibility but have not yet cleaned up the decision path behind it.

Read that beside How a Voice Technology Pilot Changed Safety Signal Governance. The pattern is the same. More reporting only helps when the owner, the verification step, and the work change move at the same speed.

Why trust and monitoring pressure must be tested

Technology can change trust even when it does not change the work itself. If workers think the new system is mostly watching them, they may give cleaner answers and less honest ones. That is a psychosocial risk, because the tool then shifts the quality of what people are willing to report.

Cam Stevens gives leaders the boundary they need when he says, "We can elevate the human experience with technology, but there are certainly times when technology should absolutely not be used." The point is not anti-technology. The point is to reject a rollout when the extra visibility comes with more fear, more self-censorship, or more monitoring pressure than the work can bear.

Across more than 30 countries of organizational context, Andreza Araujo's work has shown that what leaders reward becomes the real system. If the pilot rewards volume, but not timely action, the team learns to feed the system instead of trusting it. If the pilot rewards speed, but not verification, it trains people to look active instead of being effective.

Technology-first versus problem-first

The comparison below is the clearest way to read Episode 15. It shows why a rollout can look modern and still fail the field test.

The table also shows why the category here is psychosocial-risks, not software features. A tool can produce 90 percent adoption and still raise complaint volume, rework, or silence. That is a better signal than a vanity metric, because it reveals the real cost of the rollout.

What leaders should do in the first 30 days

Use the first 30 days to test whether the new system changes work, not just reporting. Start with a 2-week problem definition sprint, then write the five fields that must be clear before scale: problem, owner, response clock, verification method, and field change. If the sponsor cannot write those five items plainly, the pilot is not ready.

Then test one live signal end to end. Ask whether the concern reached the right owner in under 24 hours, whether the next shift saw a change, whether the team felt any added pressure, and whether the result improved or only looked organized. That is the kind of review that matches Cam Stevens' thesis and Andreza Araujo's practical bias toward field proof.

For a broader risk lens, compare this article with Psychosocial Risk From Technology: 30-Day Audit and Technology Change: 5 Distortions in Psychosocial Risk. Together, they show why technology change has to be managed like a work-design decision, not a communications campaign.

Three traps the market still misses

The first trap is to confuse visibility with control. A cleaner dashboard is not the same as a safer workplace, because visibility does not move a barrier by itself. The second trap is to treat added monitoring as a free good. When the team starts feeling watched, the organization may get more compliance theater and less candor.

The third trap is to assume the digital problem is technical when it is usually managerial. If the owner cannot act within 24 hours, if the next shift cannot verify the fix, or if the tool creates more rework than the old process, then the issue is not the interface. The issue is the decision model.

Andreza Araujo has seen this pattern in more than 250 cultural transformation projects, and the lesson stays consistent. The field does not need another layer of activity. It needs a system that changes the next decision quickly enough to matter.

Recommendation

Leaders should use Episode 15 as a 30-day governance review for one live digital pilot. Start with a 2-week definition sprint, then test the five fields again before scale. If the sponsor cannot name the problem, the owner, the response clock, the verification method, and the field change, the pilot is not ready for broader use.

As a final filter, ask whether the tool reduced psychosocial load or increased it. If the answer is unclear, pause the rollout, narrow the use case, or redesign the workflow before the system teaches people to stay quiet. That is the practical value of Cam Stevens' warning and the reason the episode matters to leaders who want safer work, not just more data.

Listen to the full conversation: Listen to the full conversation.