How Cam Stevens Thinks About Defining the Safety Problem Before Choosing Technology

Episode 15 of Headline Podcast, published on March 18, 2026, brought safety technologist Cam Stevens into conversation with Andreza Araujo and Dr. Megan Tranter. His central argument is that leaders should define the work problem and the decision it affects before they open a technology catalog.

Why the problem must come before the tool

Safety technology creates value when it improves a defined operational decision, not when it merely adds another digital layer. In Episode 15, Cam Stevens separates problem-first selection from tool-first enthusiasm, which gives leaders a practical test for every pilot: identify the exposure, the user, the decision, and the field change that should be visible within 30 days.

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." That distinction matters because most technology proposals arrive with a polished interface, a short implementation plan, and an unclear answer to the question that should govern the investment: what will people decide differently?

Andreza Araujo's work across more than 250 cultural transformation projects points to the same leadership discipline. A safety intervention only becomes part of culture when it changes the repeated choices that shape exposure, supervision, and control verification. Installation is not adoption, and adoption is not protection.

What a useful safety problem statement contains

A useful safety problem statement names the work, exposure, decision, owner, and evidence that will confirm improvement. The brief should fit on one page and answer 5 questions before procurement starts, including where the risk appears, who can act, and how the team will know that the work changed rather than only the reporting system.

Start with the work condition rather than the product category. "We need artificial intelligence" is not a problem statement. "Maintenance supervisors receive incomplete information about stored energy before 6 recurring task types, and the authorization decision is delayed or made on assumption" is specific enough to test.

The second layer is decision ownership. A sensor, app, or voice system cannot control risk by itself. Someone must decide whether to stop, isolate, redesign, re-sequence, or continue the work. The brief should name that person, the time available, and the evidence they need.

This approach also fits the practical orientation in Safety Culture: From Theory to Practice by Andreza Araujo, where culture is treated as a pattern of decisions and conditions rather than a poster campaign. The technology question becomes narrower and stronger because the team first decides which behavior, barrier, or management routine needs to change.

How to separate signals from prediction hype

A safety signal describes a condition that can support a decision, while a prediction claim promises more certainty than the data may justify. Leaders should test the source, timing, accuracy, actionability, and owner of every signal before treating it as a leading indicator or an early warning.

Episode 15 includes a warning about prediction hype. A system may identify patterns in 10,000 records, yet still fail to tell a supervisor what to do during the next 10 minutes of work. The relevant question is not whether the model is impressive. It is whether the signal arrives early enough, reaches the right person, and changes a control.

Use a simple evidence ladder. At the first level, the system reports an observation. At the second, a person interprets the observation. At the third, an owner acts. At the fourth, the field verifies whether exposure changed. A project that stops at level one is a dashboard, not a control.

Safety leaders should also record false positives and missed signals during the first 4 weeks. If the team celebrates alert volume while ignoring response quality, the technology can make the operation look more attentive without making it safer.

Where technology can increase psychosocial risk

Technology increases psychosocial risk when it expands surveillance, reporting pressure, or performance comparison without increasing worker control. Cam Stevens describes technology-driven psychosocial risk as a major shift in the risk profile, so leaders must examine workload, autonomy, contestability, and the human response to every new data stream.

The risk often appears after the launch, when a useful signal becomes a target. A voice report that helps a worker describe a hazard can become a daily scorecard if managers rank teams by submissions. An alert that helps a supervisor see fatigue can become another notification burden when the supervisor already owns 12 unresolved actions.

Ask 4 questions before collecting a new signal. Who is being observed? Who can challenge the interpretation? What happens when the signal is wrong? Which existing task will be removed to make room for the new response? If leaders cannot answer the fourth question, the project may be adding work instead of reducing exposure.

Headline Podcast's conversation with Cam Stevens makes this a leadership issue because technology changes the relationship between people, information, and authority. Araujo's perspective is useful here: the system should help leaders see and act on risk, not create a cleaner record of pressure that workers cannot contest.

What a 30-day pilot should verify

A 30-day pilot should verify whether the technology improves a named decision under real work conditions. The review needs a baseline from the previous 4 weeks, 3 success measures, a frontline owner, a stop condition, and evidence that the control changed rather than only the number of records or alerts.

Choose one operation, one exposure, and one decision route. Measure response time, decision quality, and field verification, then add one burden measure such as minutes per shift spent reviewing alerts. The pilot should include at least 2 frontline users and the supervisor who owns the work, because a tool tested only by the project team cannot reveal the practical friction of adoption.

Set a stop condition before launch. Stop or redesign the pilot if false alerts exceed the agreed threshold, if workers cannot challenge a classification, if the response adds more than 15 minutes per shift without removing another task, or if the control owner cannot act on the information.

The 30-day review should end with one of 3 decisions: stop, adjust, or scale. Each decision needs evidence, a named owner, and a date for field verification. This keeps technology governance connected to operational leadership rather than leaving it inside procurement or IT.

Technology-first versus problem-first leadership

Technology-first leadership asks whether a tool can be installed, while problem-first leadership asks whether a defined exposure and decision will improve. The difference is visible in the evidence leaders request, the people included in the pilot, and the point at which the organization is willing to stop spending.

The table does not reject technology. It places technology behind a stronger governance sequence. Leaders can still move quickly, but speed must apply to learning about the problem rather than to purchasing the most persuasive interface.

Andreza Araujo's executive EHS experience reinforces this distinction. When a program reaches multiple countries or business units, a weak problem definition scales confusion just as efficiently as a good system scales control. The first decision therefore belongs to the operational leader who understands the work, not only to the person who owns the digital project.

How leaders should decide what not to automate

Leaders should not automate a decision when the data is too weak, the consequence is too serious for an opaque rule, or the worker cannot challenge the result. Cam Stevens argues that technology should elevate the human experience in some situations and remain unused in others, which makes restraint part of responsible safety leadership.

Do not automate the final decision simply because a system can rank options. Keep human authority visible when the work involves uncertain evidence, conflicting controls, or a serious consequence. Automation may sort information, but the person accountable for the work must still understand the basis for action.

Write the boundary into the pilot charter. The system may surface a pattern, recommend a review, or remind a supervisor about a control. It may not silently convert an incomplete signal into a disciplinary conclusion, a work authorization, or a claim that the operation is safe.

This boundary protects both the worker and the leader. It also improves learning, because a visible decision can be questioned, corrected, and compared with the field result. A hidden rule leaves the organization with an outcome but no usable explanation.

Recommendation

Before approving the next safety technology pilot, require a one-page problem statement, one operational owner, 3 success measures, a 30-day review, and a written boundary for automation. The decision should be based on changed work and control quality, not on installation, alert volume, or the number of people who logged in.

Choose one live problem that supervisors already recognize, then describe the exposure, decision, timing, and evidence in plain language. Interview 2 workers and 2 supervisors before selecting a tool, because their account of friction will often reveal a simpler control that the technology proposal has hidden.

Use the pilot to test whether information reaches authority before the work becomes irreversible. If the tool creates more reporting, more alerts, or more pressure, redesign the process rather than asking the workforce to absorb the cost. Read the related Episode 15 analysis on safety signals before the review meeting.

Conclusion

Cam Stevens's Episode 15 lesson is a governance rule for safety leaders: define the work problem before choosing technology, then verify that the tool changes a decision without creating new pressure. The strongest pilot may end with a different tool, a simpler control, or a decision not to automate.

Headline Podcast's conversation with Cam Stevens gives leaders a practical way to resist tool-led momentum. Name the problem, give the decision an owner, measure the field change, and stop when the evidence does not support scale. That sequence protects the quality of safety leadership while keeping technology in its proper role.

Listen to the full conversation with Cam Stevens on Headline Podcast.