How Cam Stevens Thinks About Technology Before It Changes the Risk Profile

Episode 15 of the Headline Podcast, published on March 18, 2026, featured Cam Stevens, CEO of PKG, in a conversation about technology and safety. Stevens defended a problem-first discipline because technology can improve the human experience while also changing the risk profile faster than a management system can notice.

Technology is a safety decision before it is a safety product

Stevens began with a distinction that senior leaders often skip. A technology catalog does not tell an organization which problem deserves investment, which exposure is changing, or which human decision the tool should strengthen. Those questions must come first, because a polished product can still automate the wrong assumption.

His warning is especially relevant to psychosocial risk. A new voice system, dashboard, wearable, or algorithm can alter pace, monitoring, autonomy, and the way workers receive feedback. If leaders evaluate only the device, they may miss the work-design consequences that appear in the first 30 days after implementation.

Cam Stevens put the issue plainly 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.”

That sentence gives executives a useful first gate. Before approving a pilot, write one problem statement, identify one exposed work group, and name the decision the technology must improve. If the proposal cannot survive those 3 questions, the organization is not ready to buy.

The risk profile can change after the rollout

Technology projects are usually approved against the risk picture that exists before deployment. Yet the tool can change workload, attention, communication, and the distribution of responsibility. A system that removes one manual burden may introduce constant alerts, tighter performance surveillance, or a new expectation that workers remain available across every shift.

This is why psychosocial risk belongs in the technology review rather than in a separate wellness program. The relevant question is not whether people like the interface. Leaders need to ask whether the new arrangement increases control over work, reduces unnecessary friction, or creates pressure that was absent before.

Stevens described this shift in the episode by saying, “The changing shift in risk profile will be overwhelmingly psychosocial, driven by technology usage in our organizations.” His point is not that every technology rollout produces harm. It is that the organization needs a way to detect changed exposure before performance data disguises it.

A practical review can use 4 lenses, namely workload, autonomy, social connection, and recovery. Compare the planned state with the first 2 weeks of real operation, then repeat the check at day 30, because early enthusiasm often hides the extra coordination that workers are absorbing.

Prediction is not the same as usable signal

Leaders are often promised prediction when the available system can only describe patterns. That difference matters in safety. A dashboard may show a correlation between voice data and fatigue, yet the organization still needs to decide what the signal means, who reviews it, and what action is justified without turning a worker into a score.

Stevens challenged prediction hype by returning to the problem the organization is actually trying to solve. A signal becomes useful when it changes a decision at the right time. If the tool produces 8 alerts and no clear owner, it has not created control. It has created another queue for an already busy team.

Andreza Araujo’s leadership perspective strengthens this point. In more than 250 cultural transformation projects, her work has centered on turning safety expectations into operating choices, not merely adding another layer of communication. A technology initiative should therefore specify the decision pathway before it specifies the dashboard design.

One useful test asks whether the signal can answer 3 questions without exposing unnecessary personal information. What changed, who is authorized to respond, and what will be different in the next shift? If the system cannot support those answers, the organization should narrow the claim rather than expand the surveillance.

Voice technology can reveal work, but it can also reshape trust

Stevens discussed voice technology as a possible data source, which creates both an operational opportunity and a trust obligation. Voice data can help leaders notice recurring friction in procedures, handoffs, or work instructions. It can also make people feel observed in ways that are difficult to reverse once the system becomes part of daily work.

The distinction between listening to work and monitoring individuals must be explicit. A responsible design explains what is collected, what is not collected, who can access the output, how long it is retained, and which decisions the data cannot support. Without those boundaries, the technology may reduce speaking up even while it promises better information.

This connects with the Headline conversation featuring Dr. Megan Tranter, whose role as co-host keeps the discussion close to the human consequences of management choices. Psychological safety is not created by a data stream. It depends on whether workers believe that raising a concern will lead to a fair operational response rather than a personal label.

Run a 6-question trust check before launch. Ask workers what they think the tool hears, which uses concern them, what benefit they expect, how an error can be corrected, who receives an escalation, and whether they can decline a nonessential use without retaliation. The answers are risk evidence, not a public-relations exercise.

Technology should support judgment, not replace it

Stevens also cautioned that there are times when technology should not be used at all. That boundary is important because the availability of a tool can create pressure to deploy it simply because the organization has already paid for it or because a competitor has announced a pilot.

Senior leaders should distinguish between augmentation and substitution. Augmentation gives people better information while preserving authority to question it. Substitution transfers judgment to an automated output and treats disagreement as a defect. In high-consequence work, that difference can decide whether a weak signal is investigated or ignored.

The comparison below keeps the decision practical.

When the tool cannot improve the decision without weakening trust or autonomy, not deploying it is a valid safety decision. That is not resistance to innovation. It is governance.

Leaders need a human review around every technical signal

A technical signal is only one part of a control system. The organization still needs a person who can interpret context, speak with the affected team, and decide whether the condition requires an immediate change. This is where leadership quality becomes visible, because an impressive system can still fail if nobody owns the response.

Set 2 owners for each critical signal, one primary and one backup, and define a response window that matches the possible harm. Record the reason for each decision, including the decision to take no action. That record helps the organization learn whether the signal was weak, the interpretation was poor, or the work system made action difficult.

Managers should also compare technical output with worker accounts. If the dashboard says conditions are stable while the team reports rising interruptions, shortened recovery, or fear of being monitored, the disagreement is not noise. It is a prompt to inspect the assumptions built into the tool.

James Reason’s work on latent failures remains useful here because the visible output rarely explains the whole pathway to harm. The design choice, procurement decision, staffing model, and local incentive may sit several layers away from the moment when a worker experiences the new pressure.

Recommendation

Choose one technology rollout that has been approved but not yet scaled, and run an 8-point review with the people who will use it. Define the problem, identify the changed psychosocial exposure, test the data boundary, name the response owners, and compare the planned workflow with the real workflow.

Then run a 30-day pilot with a stop rule. Stop or redesign the rollout if the tool increases avoidable workload, weakens speaking up, creates ambiguous accountability, or produces alerts that no one can act on. A pilot is not successful because the software works. It is successful when the work becomes safer and the decision becomes clearer.

Cam Stevens’s central argument is a useful discipline for every executive considering safety technology. Start with the problem, protect human judgment, and treat a changed risk profile as a management signal rather than an unfortunate side effect.

Listen to the full Episode 15 conversation with Cam Stevens on the Headline Podcast, then compare its problem-first test with your next technology decision. You can also continue with the Headline Podcast analysis of AI rollouts and psychosocial risk, the guide to workload thresholds, and the discussion of technology and safety culture beyond compliance.