It's no secret that building a data-driven culture in a company is hard, but what is it exactly that makes this such a tricky endeavor?
Contrary to popular belief, technology isn't the main hurdle. A recent survey reveals that only a quarter of respondents cite technological limitations as the primary obstacle to becoming data-driven.
In my opinion, building a data-driven company culture is ultimately an organizational problem that involves people and processes, and establishing a shared collection of 'data habits' that are collectively reinforced. Outside of the conventional baseline requirement for dashboards and reporting, we've come up with some tried and tested strategies to keep data top-of-mind across the company.
One of the easiest ways to drive data asset adoption and visibility is to minimize the barrier to access. A few additional clicks can make the difference between stakeholders never seeing the beautiful dashboard you built and the dashboard becoming a staple resource they view daily. Another way to think about it is: rather than relying exclusively on end-users needing to “pull” the data themselves, it’s worth trying to “push” the data to them, effectively meeting them in the middle where they are most familiar.
For example, our Sales team heavily uses Salesforce as their "default" space to view information on accounts or prospects. Rather than draw them away from the UI and workflows they're accustomed to, we leveraged Omni's (our BI tool) embed functionality to bring insight-rich reports directly into Salesforce. Use cases like embedding a customer's health score dashboard directly on the Account object, or providing a timeline of a prospect's inbound activity on the Contact's page, mean that our end-users don't have to leave a familiar system to make use of the additional insights the data team provides.
The best part? The embed URLs can be parameterized to pre-filter the data for the specific customer, opportunity, or contact the end user is currently viewing! Here's a snippet of the code used to create the Visualforce page object with the dynamic Account_Id
field in the dashboard URL.
<apex:page standardController="Account" sidebar="false">
<apex:
iframe scrolling="true"
id="omni-frame"
src="https://incident.embed-omniapp.co/dashboards/url?f--salesforce_accounts.account_id={!Account.Id}"
>
</apex:iframe>
<script>document.getElementById('omni-frame').height = window.innerHeight;</script>
</apex:page>
At incident.io, we're big fans of "pulse" channels — Slack channels where topic-specific updates are automatically posted. These cover a wide range of product, commercial, and engineering use cases, from NPS responses to app deployment results.
These pulses promote organization-wide awareness of important matters — think deals progressing through opportunity stages, customers signing up for our self-serve plan, or monthly revenue growth roundups. They ensure the whole organization stays regularly updated with relevant information.
Beyond general updates, we also leverage these pulse channels at the department or team level. For instance, we've set up a number of bespoke alerts for the Customer Success team, notifying them when key users hit usage milestones, when we haven't heard from a customer in a while, or when renewals are approaching. We make team-specific alerts immediately actionable by tagging relevant users (e.g., the respective Customer Success Manager for customer-related alerts or the Sales representative for prospect-related ones) and linking to relevant resources like dashboards or playbooks.
We use Hightouch to power the vast majority of these alerts. Hightouch is a reverse-ETL app that connects to our data warehouse and periodically sends updates to specific Slack channels. The ability to combine data from multiple sources (e.g., Billing, CRM, Product) into well-formatted messages with clear scheduling logic is incredibly effective and valuable.
It's worth noting the obvious risk with these pulse channels — an overwhelming amount of noise. This could lead to people either ignoring alerts by default and missing crucial information, or seeing alerts and thinking "So what?" without taking action. To prevent this, we ensure that alerts intended for specific subsets of people (rather than for general company awareness) are both intentional (high signal, low noise) and actionable (clearly stating who needs to do what).
When dissecting why a company is data-driven, it often boils down to a collection of smaller behaviors and habits that are collectively encouraged and reinforced. Here are some more small ways in which we promote a data-driven culture at incident.io:
In conclusion, building a data-driven culture goes beyond technology implementation; it's about cultivating organizational habits that prioritize data in decision-making. The key is making data accessible, relevant, and (wherever possible) actionable for all stakeholders.
These strategies demystify data, encouraging its regular use and transforming it into an integral part of how the company thinks and operates. Consistent reinforcement of these practices builds a culture where data-driven decision-making becomes instinctive.
We developed The Fatigue Score to make sure our On-call responders’ efforts are visible. Here's how we did it, and how you can too.
What does "good" incident management look like? MTTx metrics track speed, but speed alone doesn’t mean success. So, we decided to analyze 100,000+ incident from companies of all sizes to identify a set of new benchmarks for every stage of the incident lifecycle.
We take handling sensitive customer data seriously. This blog explains how we manage PII and confidential data in BigQuery through default masking, automated tagging, and strict access controls.
Ready for modern incident management? Book a call with one our of our experts today.