Scaling engineering organizations often suffer from fragmented operational data. This unified platform approach demonstrates how to build a single source of truth for engineering health, improving decision-making efficiency and metric consistency across thousands of engineers.
By Shiva Nimmagadda, Arun Lakshmi Narayanan, and Arun Gangavarapu.
Salesforce engineering teams encountered a significant operational hurdle as the organization scaled. Critical data lived across dozens of fragmented dashboards and systems, each maintaining its own definitions. This chaos forced teams to navigate up to 40 separate tools just to complete basic engineering reviews. Leaders lacked a consistent method to evaluate team efficiency or a single source of truth for operational health.
Engineering 360 emerged as the solution to these systemic inefficiencies. While the project started as a simple productivity dashboard, it evolved into a unified platform that consolidates data and decision-making. The system now tracks 150 standardized metrics. Currently, 80% of engineering managers rely on this platform to conduct their operational reviews.
This evolution involved overcoming complex obstacles in data unification and metric standardization. Success required the team to prioritize system reliability and platform performance at every stage of development.
The team first addressed fragmentation across systems with inconsistent schemas and identifiers. Since individual engineers often held multiple identities across various tools, core concepts like ownership varied depending on the source. This lack of cohesion made consistent analysis nearly impossible at the scale of Salesforce.
Unifying this data required a strategy beyond simple aggregation. The team utilized Data 360 to ingest information from Git, Workday, and internal platforms before normalizing it into a common model. Identity resolution then mapped disparate identifiers into a single representation to track activity and ownership accurately.
Reconstructing relationships across these datasets proved equally vital. Signals from different systems required precise joining to preserve their original meaning while enabling broad analysis. This transformation turned heterogeneous data into a shared operational model, shifting Engineering 360 from disconnected views to a centralized visibility platform.
Unified data shifted the focus to a new challenge: defining what to measure while enforcing consistency across a massive organization. As the platform expanded to cover availability, quality, and security, teams introduced conflicting reporting patterns. These discrepancies threatened to recreate the exact fragmentation the platform aimed to eliminate.
The sheer scale of the project complicated standardization efforts. Metric requests grew rapidly, and hundreds of candidates competed for inclusion in the system. Without firm control, the platform risked becoming a high-volume reporting layer with very little operational value.
The team responded by enforcing a strict framework for every metric. Each indicator required a clear definition, alignment with organizational goals, and direct actionability. Leaders evaluated metrics as leading or lagging indicators, excluding any that failed to drive decisions or scale effectively.
Reducing hundreds of requests to a standardized set required deliberate tradeoffs and strong alignment among leadership. This rigorous consistency now ensures that engineering reviews operate on a shared understanding of system health rather than individual interpretations.
As Engineering 360 became the standard for engineering reviews, trust emerged as a non-negotiable requirement. Any data inaccuracy or delay would cause teams to revert to spreadsheets or isolated dashboards. Such a shift would collapse the platform back into the fragmented state it aimed to replace.
The team operated the platform as a live service, implementing monitoring across all data pipelines. Failures triggered immediate alerts and rapid remediation to maintain data integrity. Defined refresh intervals provided predictability, allowing users to rely on current data during critical operational reviews.
Governance added further complexity to the system. While some datasets required broad visibility, others demanded strict access controls. Role-based access and compliance approvals protected sensitive information without hindering operational use.
Trust involves more than mere correctness. The system must behave predictably under constant use to support decision-making at scale.
As Engineering 360 scaled, performance became a structural constraint. Dashboards relied on joins across multiple pipelines, and accumulating historical data increased query complexity. When queries spanned years of data and multiple sources, performance degradation became unavoidable.
Early implementations relied on complex SQL within the visualization layer. This approach introduced latency as datasets joined and history grew. At scale, these joins created a bottleneck that directly impacted usability.
The team addressed these issues by restructuring the processing. They pushed transformations upstream and pre-aggregated data to reduce runtime complexity. The transition to Tableau Next further improved performance by separating data, semantic, and visualization layers. This separation allowed each layer to scale independently.
These changes reduced latency significantly. The platform now remains responsive even as data volume, usage, and system complexity continue to grow.
Standardization requires more than just functional architecture. It demands a fundamental shift in behavior. Engineers and managers often cling to familiar workflows and legacy tools. Resistance naturally follows when a new system threatens these established habits.
The team overcame this by embedding Engineering 360 directly into operational reviews. This move established the platform as the primary source for evaluating engineering health. It phased out fragmented spreadsheets and team-specific dashboards in favor of a unified operational model.
Support for this transition included comprehensive documentation and internal training sessions. The platform maintains consistency while offering enough flexibility to accommodate unique team processes and edge cases.
These efforts solidified the system as a core operational pillar. Approximately 80% of engineering managers now use Engineering 360 every month.
Evolution requires moving beyond simple activity tracking. Engineering 360 now transitions from a visibility tool into a system that enables engineering operations at scale. The current focus shifts the platform toward active decision-making.
The platform develops predictive insights by correlating signals across various metrics. This approach identifies bottlenecks and guides specific actions rather than just displaying data. The next stage addresses complex challenges like measuring AI-driven productivity and replacing lagging indicators with leading ones.
Engineering 360 functions as more than a dashboard. It serves as a system designed to drive decisions and foster proactive workflows across the organization.
The post How Engineering 360 Unified Operations at Scale and Reached 80% Adoption appeared first on Salesforce Engineering Blog.
Continue reading on the original blog to support the author
Read full articleCode coverage is often a structural issue rather than a testing one. By removing boilerplate and excluding generated code from metrics, teams can satisfy CI gates while improving maintainability and reducing pipeline overhead without adding low-value tests.
Traditional logs fail to capture the data context of AI responses. This query-driven approach allows engineers to inspect the exact document chunks and embeddings used in production, slashing debugging time from weeks to hours while maintaining strict data isolation.
This system demonstrates how to transform massive, fragmented telemetry into actionable insights. By standardizing health metrics and isolating analytics from production, engineers can proactively identify risks, reduce support overhead, and ensure platform stability at a petabyte scale.
Automating large-scale infrastructure migrations is critical for reducing operational risk. MIPS demonstrates how to build a deterministic decision engine that maintains auditability and customer trust while scaling to handle tens of thousands of complex organization moves.
