Building Data Champions Inside Business Units

Somewhere between the dashboard launch and the "adoption metrics" meeting, most data teams hit the same wall. They build the thing. They demo the thing. They send the messaging-app announcement about the thing. And months later, almost nobody's opened it.

This isn't a tooling problem. The dashboards work fine. The models run fine. The gap is human, not technical, and it shows up in the numbers before anyone even gets to root cause: per Gartner, 87% of organizations rated themselves as low in BI and analytics maturity. That's not a handful of laggards. That's nearly every organization tripping over the same rock.

Two failure modes tend to compound each other here. First, tools get rolled out broadly but stay too complex for the average employee to self-serve, so the project delivers little real benefit despite the investment. Second, when the central data team can't keep up with requests, business units go build their own workarounds. Spreadsheets nobody vetted. Shadow databases. "Stealth" analytics living entirely outside IT's view, quietly creating security risk and duplicate work.

That second pattern is the more interesting one, honestly. Stop and think about what it actually means. A business unit builds an unofficial data solution because getting the official one takes too long or delivers too little. That's not resistance to data. That's demand for data, so strong that people would rather risk it than wait for it. The demand was never the problem. The delivery model was.

Which raises the real question this piece is built around: not "how do we build a better tool," but "how do we build the human infrastructure that gets people to actually use the tool we already have?" That infrastructure has a name, and it's not a job title on an org chart. It's the data champion.

What a data champion actually is, and what they are not

A data champion pushes their team toward data-driven decisions, spreads good analytics habits, and translates between the technical data team and the business side that has to act on what the data says. Part organizational leader, part process builder, part governance steward, all inside a single unassuming job.

What actually separates a champion from just "the person on the team who's good with Excel"? Three things, roughly:

Communication: they can take a messy finding and turn it into a plain recommendation someone in ops or sales can act on today. Pain-point fluency: they know exactly where their team's workflow breaks, not just how to run a query. Curiosity: they ask about the numbers their team already tracks, unprompted, because they actually want to know the answer.

Now, what a champion is not. This matters just as much:

• Not a new hire. The role lives inside people already on the team.
• Not necessarily the manager, and not necessarily the most technical person in the room.
• Not a full-time analyst in disguise. The role sits on top of an existing job, not instead of it.

Here's the thing that makes the role work at all: a champion has to stand in two places at once. They know the business unit's day-to-day from the inside, and they're also the direct line to the data team. A purely technical person can't do that job. Neither can a purely business-side person with no interest in the numbers. It has to be both, in one person.

One more honest note: champions will hit resistance. That's not a sign the program failed. Pushing for change always draws some friction, from colleagues who liked the old spreadsheet or managers who don't see the point yet. Name that upfront, and it stops looking like failure when it shows up.

How to spot potential champions before you recruit them

Forget the resume. The signal worth tracking is behavioral: who's already asking data questions nobody assigned them? Who looks at the current workflow and says "this isn't good enough" and keeps pushing anyway?

A few markers tend to show up in ordinary, unglamorous work:

• They pull more data than the report handed to them. They go looking at adjacent metrics or cut the numbers a different way.
• They explain findings to teammates without being asked to.
• They complain about data, specifically. Not "the reports are bad" but "this field is missing" or "this number doesn't match that other number."

Gulf Bank's experience offers a useful case here. Two teams ran the same campaign. One team stopped once the headline metric flattened. The other, call it Team B, noticed something the headline number missed, membership was ticking up, and people were buying things outside the campaign's own scope. Team B kept the campaign running because they'd gone looking past the obvious number. That instinct, right there, is what a champion looks like in the wild.

As for scale, Gulf Bank's Chief Data Officer at the time, Mai AlOwaish, speaking at DataCamp's RADAR conference, put the ratio at roughly one in ten: in a data-driven organization, about that share of people tend to be naturally data-inclined. Gulf Bank found 140 Data Ambassadors out of a head-office population of roughly 1,000. That's a useful planning number if you're scoping a champion cohort of your own.

Who actually qualifies? Anyone who touches data in the department, full stop. No data science degree required. And don't limit the search to the obviously analytical teams, either. Gulf Bank placed champions in consumer banking, human resources, risk management, and IT, departments that don't usually make the "data culture" highlight reel.

One practical note: informal conversations and nominations, whether peer-suggested or manager-suggested, tend to surface people a skills inventory would completely miss. The best champion candidate rarely lists "data analysis" as a skill on anything official.

Structuring the champion role so it actually works alongside a day job

Here's the tension that kills most champion programs before they start: the role is additive. It sits on top of a full workload, not instead of it. Ignore that, and the role collapses the second a real deadline hits.

Letting champions shape the role around their own strengths and time gives them ownership of something realistic, instead of a mandate handed down from above that they quietly resent.

In exchange, the organization owes them a few concrete things:

Visible backing from managers and execs, so the champion's push for better data isn't dismissed as a personal quirk. Context on the bigger analytics strategy, so champions understand how their piece fits the whole. Protected time: even a modest, explicit block. Without it, the role always loses to whatever's on fire that week.

Beyond that, a few formal mechanics reduce ambiguity that would otherwise eat the program alive:

• A written scope. What's in (first point of contact for data questions, flagging data quality issues, helping onboard new tools) and what's out.
• A named liaison on the central data team. Not a full reporting line, just someone to call.
• A regular cadence of check-ins, not "whenever it comes up."

And there's a governance layer baked into the role, too. Champions become the local stewards of what data their team can see, how key metrics get defined, and who to escalate the weird edge cases to. That's not a side effect of the role. It's part of the job description.

What to teach champions, and in what order

Start with the business problem, not the software. Champions who learn a platform's interface before they understand what question it's supposed to answer tend to get stuck exactly at the demo stage and never move past it.

A rough teaching order that tends to hold up:

1. Data quality first. What "good data" means for this specific team's decisions. This is upstream of everything else and prevents the most common mistakes.
2. Interpretation. Reading a chart critically. Knowing what a metric doesn't tell you. Telling correlation apart from an actual signal worth acting on.
3. Visualization. Not just consuming a dashboard someone else built, but building and reading one.
4. Self-serve querying. Enough to answer a quick question without filing a ticket. Even guided, no-code querying counts here.
5. Automation basics. Reducing repetitive manual reporting that eats a Tuesday morning.

Gulf Bank's curriculum tracked this closely: workshops on data quality, visualization, and automation, plus dedicated training on a self-serve analytics tool. The program ran a full year and ended with an actual graduation ceremony, which sounds small but does a lot of work for morale.

The tooling has to meet champions where they actually are. If getting anything useful out of a platform requires writing SQL or a modeling language, only the already-technical champions will make it through, and the rest wash out. The tool needs to let someone explore and build without an engineer standing over their shoulder for every query.

Lightweight tools that connect directly to the database but expose only governed, permissioned views work well here. Champions get real access to what their team actually needs, without ever touching raw credentials. That alone drops the skill floor for the whole program.

One caution worth repeating: don't train people on a tool nobody's going to keep using after the program ends. Curriculum and tooling decisions need to happen together, not one dictating the other after the fact.

Why governance and access design determine whether champions succeed or hit a wall

Here's the paradox nobody warns you about: open up access faster than the organization can actually govern it, and self-serve turns into a mess of mismatched reports and conflicting numbers. Two champions build two different versions of "active users," both technically defensible, both wrong in different rooms. That's not a hypothetical. That's what happens when access outruns definition.

The fix isn't slower access. It's a shared, governed definition of what the key metrics actually mean, sometimes called a semantic layer, that every champion works from instead of inventing their own. This single piece is probably the strongest predictor of whether self-serve analytics survives first contact with a real, messy organization.

What access architecture needs to hand champions:

Role-based access and row-level security, so a champion sees what their team needs and nothing more. Trust signals on dashboards: a clear label for "this is the official governed number" versus "this is someone's exploratory cut." Safe write paths where needed: teams in support, ops, or sales that need to edit records should get permissioned editing, not a shared login and a prayer.

The infrastructure gap here is real, and recent numbers back it up: as of 2025, 68% of organizations run a centralized data platform capable of self-service analytics, but only 20% have turned on natural language querying for business users. The plumbing exists almost everywhere. The usability layer for non-technical champions mostly doesn't.

Put simply: if the only way to keep data safe is to keep people out of it, self-serve already failed before it started. Getting this right is squarely the data and engineering team's job, and it has to happen before champions are handed the keys, not after.

Building the community and incentive structure that keeps champions engaged

"What's in it for me?" isn't a cynical question. It's the honest test of whether a champion program survives past its launch quarter. If the role gives someone nothing they can point to, it loses to their actual job every single time, guaranteed.

A few incentive mechanisms that hold up in practice:

Public recognition: Gulf Bank marked its Data Ambassador graduation with a formal celebration. Visibility tells the whole organization the role is taken seriously. Portable credentials: something that reads well on a resume, not just an internal badge nobody outside the company understands. Career framing: the role builds cross-functional influence and analytical skill, both of which help someone's career whether they stay in that seat or not. Earlier access: champions get first crack at new data capabilities, which makes the role tangibly useful to their own work, not just a favor to the company.

Beyond individual incentives, a community of practice does the heavier lifting. A regular forum where champions across departments compare notes, surface the same recurring question three different teams have been asking separately, and flag data quality issues together. This is where the lateral spread this whole model depends on actually happens, peer to peer, not memo to memo.

That community also feeds back to the data team. Champions collectively surface the patterns in what business units keep failing to find or do, and that pattern becomes the technical team's priority list.

And when resistance resurfaces (it will, even after the initial enthusiasm), the community is where champions process it with people who get exactly what they're up against, instead of absorbing it alone.

How a champion network drives lateral data adoption (the Gulf Bank example)

Gulf Bank's program is worth walking through in full because it shows the sequencing, not just the ingredients.

Mai AlOwaish, the bank's former Chief Data and Innovation Officer, described the effort at DataCamp's RADAR conference in a talk titled "Building Data Champions at Gulf Bank: Scaling Internal Data Talent Flows." The program, called Data Ambassadors, ran through 2021 and 2022 as a formal data literacy initiative.

The numbers: 140 Data Ambassadors out of a head-office population of roughly 1,000, matching the one-in-ten ratio AlOwaish described as typical for data-inclined employees in a data-driven organization. Coverage spanned consumer banking, human resources, risk management, and IT, well beyond the departments people usually assume are "the data ones."

The curriculum ran workshops on data quality, visualization, and automation, along with training on Tableau for self-serve analytics. The whole thing lasted a year and ended with a graduation.

What backed it up structurally: executive and managerial support so every department actually had an embedded champion, a curriculum built to accelerate real skill, and an incentive structure built explicitly around answering "what's in it for me?" honestly.

The outcome: champions became the go-to person for data questions inside their own departments. The data team's actual reach multiplied without the data team itself growing to match.

One sequencing detail worth sitting with: Gulf Bank built the champion network before rolling out the wider enterprise data literacy program, not after. AlOwaish's logic was that the champions needed to exist first, so the broader rollout had somewhere to land.

And AlOwaish flagged a governance wrinkle that came out of the program directly: "The data champions are crunching numbers and reading the data, but it's others who are entering the numbers. So, those doing that task need to recognize the data's value, that it has to be complete and useful for analysis." Worth sitting with, because it means the champion model only closes half the loop. The people entering the data in the first place need to care about its quality too, or the champions are just doing better analysis on the same bad inputs.

What the data and engineering team's role looks like once champions are in place

Without champions, the data team is a permanent bottleneck. Every question from every department routes through the same small group, the report backlog grows, and non-technical teams wait. As of 2025, self-service analytics has been credited with cutting report-generation backlog by 40% across organizations, which is the kind of number that explains why this whole model exists in the first place.

With champions in place, the data team's job changes shape. It shifts from answering every question personally to enabling the people who ask questions. Concretely, that means:

• Building governed, permissioned data views instead of one-off custom reports for every request.
• Maintaining shared metric definitions champions can point to and enforce inside their own departments.
• Making self-serve tooling genuinely usable without SQL, because a champion's independence depends entirely on whether the tool actually allows it.
• Producing onboarding material champions can hand to teammates without needing an engineer in the room every time.

The force-multiplier math here is straightforward: one data engineer who properly equips ten champions across ten departments reaches a volume of work that would otherwise need a far bigger team. This isn't just a culture initiative dressed up in nice language. It's an efficiency argument, plainly.

The feedback loop closes the circle. Champions run into what their tools and data can't do, and surface that back to the data team, who use it to decide what to build or expose next. That's a pull model, built from actual demand, instead of a push model built from what the data team assumed people wanted six months ago.