The testimony of former Meta engineering director Arturo Béjar serves as a case study in what happens when the mechanics of growth become decoupled from the mechanics of safety. For any operator building a product at scale, the tension is familiar: you can only optimize for a limited set of variables. When those variables are exclusively centered on user volume and engagement, the second-order effects—specifically the risks posed to vulnerable populations like children—are often treated as externalities rather than core engineering requirements.

This isn’t just a story about corporate ethics; it is a story about how organizational incentives dictate output. If a product manager is rewarded for a 5% increase in daily active users but lacks a corresponding KPI for reducing harassment reports, the choice is made before the work even begins. Béjar’s account suggests a culture where safety teams were essentially operating as a cost center, while growth teams were the revenue engine. To fix this, leadership must integrate safety metrics directly into the product development lifecycle rather than relegating them to a reactive oversight committee.

Practical implementation starts with the 'Safety Debt' audit. Just as technical debt slows down code deployment, unaddressed safety risks create a liability that compounds over time. Organizations should require a safety impact assessment for every major feature release, similar to a security review. This isn’t a suggestion for more bureaucracy; it is a requirement for operational stability. If a feature increases engagement by facilitating anonymous interactions, the engineering team must simultaneously deploy the moderation tools necessary to handle that increased volume. You do not ship the engine without the brakes.

Furthermore, the failure described at Meta highlights a breakdown in internal feedback loops. When senior leadership ignores data regarding user harm, it signals to the entire organization that the 'unglamorous' work of protection is optional. For an execution-focused leader, the takeaway is clear: your reporting structure must allow for dissent that is backed by data. If your safety lead reports through the growth department, you have a structural conflict of interest that will eventually lead to a public failure.

Executing on safety requires moving it from a philosophical goal to a technical constraint. Every dashboard tracking user growth should have a corresponding column for incident rates. If the growth curve goes up while the incident curve also rises, that is not a success; it is a failure of system design. Building for the long term means ensuring that your product remains a safe place for its users to exist, which is the only way to ensure they remain users at all.