When organisations talk about great data teams, the conversation often gravitates towards what is easiest to see: sophisticated data platforms, automated pipelines, dashboards, machine-learning models, and the technical expertise required to build them. These capabilities matter, but they tell only part of the story.
The real difference between an average data team and an exceptional one is often found in the work that happens outside the spotlight: building trust in data, understanding the business behind the numbers, aligning stakeholders, challenging assumptions, documenting decisions, and ensuring that the solutions being developed address problems that genuinely matter.
Much of this work never appears in project plans, performance metrics or executive presentations. Yet it can determine whether a data function becomes a strategic advantage or remains simply another technical service within the organisation.
Opeyemi Fabiyi is a Director of Analytics Engineering who has spent the last eight years exploring the breadth of the data industry, across data science, analytics consulting, data infrastructure and artificial intelligence. He began his career as a data scientist before moving into analytics consulting at a global professional services firm.
A strong commitment to helping others succeed underpins the community initiatives he has founded and supported, including Young Data Professionals, a community built on a simple belief: people should have access to the network, support and clarity they need to build sustainable careers in data. Beyond data, he is an enthusiastic traveller whose adventures have taken him caving, parasailing and scuba diving. He also cycles and has recently taken up running.
His personal philosophy: “Never stop learning. Never stop finding ways to give yourself an edge.”
Beyond technical talent
Talent is essential, but technical talent alone does not guarantee impact. An organisation can have highly skilled data professionals, sophisticated infrastructure and the latest tools and still struggle to translate its data capabilities into meaningful business outcomes.
What sets exceptional teams apart is their ability to understand the organisation they serve. They know what the business is trying to achieve, where the most important challenges lie, and how their work can contribute to those priorities.
This changes the way the team operates. Instead of waiting for stakeholders to submit requests, great data teams proactively identify opportunities, ask better questions, and challenge assumptions when necessary. They also recognise that building a solution is only part of the job. Finding the right internal champions and change agents who can drive adoption is equally important.
A technically excellent solution that nobody trusts, understands or uses ultimately creates little value. The strongest teams go beyond the role of technical executor. They become partners in decision-making: people the organisation can rely on not only to provide answers, but also to help identify the right questions.
Documentation discipline
One of the clearest habits of mature data teams is documentation discipline. Documentation may not be the most exciting part of data work, but it is fundamental to building a resilient function. When teams consistently document their data models, definitions, assumptions, processes and key decisions, they create institutional knowledge that extends beyond individual employees.
That knowledge becomes particularly valuable as organisations grow. It reduces dependency on specific individuals, prevents teams from repeatedly solving the same problems, improves consistency, and makes it easier for new members to contribute effectively.
The cost of poor documentation is rarely immediate. It appears gradually in duplicated work, conflicting definitions, avoidable errors, lengthy onboarding, and the inevitable question: “Who knows how this works?” Exceptional teams recognise that documenting their work is not administrative overhead. It is part of building infrastructure for the organisation’s long-term memory.
Knowing what not to build
Great data teams understand that their capacity is limited and that not every request deserves to become a project. They establish clear criteria for determining which problems are worth solving, which initiatives are likely to create meaningful value, and which should be declined or deferred.
This requires the confidence to say no. Saying no does not mean being unresponsive to the business. It means protecting the team’s ability to focus on work that matters, and asking whether a proposed dashboard, model, pipeline or analysis will actually influence a decision or improve an outcome.
The best teams do not measure their effectiveness by how much they build. They measure it by the value their work creates.
That is where data teams move from being a support function to becoming a genuine strategic partner, and where the most enduring value of data is created.
Solving the right problem: how high-performing data teams choose what matters
The best teams often start with one question: what decision does this enable? If the answer is vague, if the person asking can’t clearly articulate how the output will change a behaviour or a business outcome, that’s a signal to pause before committing resources.
Not every interesting problem is valuable, and not every valuable problem is the right one to solve right now.
High-performing teams have a clear sense of where they can create asymmetric impact. They aren’t trying to solve everything. Instead, they identify the handful of problems where their work will generate disproportionate value, and concentrate their energy there. That kind of focus is a discipline, one that requires teams to be honest about opportunity cost in a way average teams rarely are.
Such teams have also mastered not letting perfect become the enemy of good. A solid solution delivered now, one that captures the low-hanging fruit and builds stakeholder trust, is often worth more than a technically superior solution that takes three times as long to ship. Delivering value early and iterating isn’t a compromise; it’s a strategy.
The trade-off trap: balancing business priorities with technical excellence
The honest answer is that technical excellence should always serve business priorities, not the other way around. Often, teams disappear into months of infrastructure work, building the perfect solution to a problem the business stopped caring about halfway through. That isn’t excellence; it’s misaligned effort dressed up as craft.
I’ve worked on a project where the technical solution was genuinely solid, but it stalled because senior stakeholders had conflicting views on what the output should prioritise, and reaching consensus proved harder than anything on the technical side. Every time we thought we’d agreed on a direction, a different perspective pulled the scope somewhere else. The project eventually delivered something, but it was a fraction of what it could have been. The technical work was never the bottleneck; the absence of a clear decision-maker was.
The most useful balance is being excellent about the things that matter most to the outcome, and pragmatic about everything else. Knowing which is which requires a level of business understanding that purely technical professionals often underinvest in.
Caught in the middle: when stakeholders want conflicting outcomes
Do not start building until the conflict is resolved. That is the most important thing. The instinct is often to satisfy everyone by scoping a solution broad enough to cover multiple interpretations, but that almost always produces something that serves nobody particularly well.
The data team’s role in that moment isn’t to pick a side, but to surface the conflict clearly and escalate it to whoever has the authority to make the call. Frame it as a prioritisation decision, not a technical one, because that’s what it actually is. Once you have a clear decision, build to it. Revisit the other priorities in the next cycle if they remain relevant.
When the numbers say no: navigating data that contradicts leadership
Presenting the data isn’t optional, but how you present it can make or break the conversation.
The mistake is framing it as the data versus leadership’s position, because that creates a defensive dynamic where the instinct is to challenge the finding rather than engage with it. The more useful framing is to present the data as additional context that sharpens the decision, not as a verdict on whether leadership is right or wrong.
It also helps to go in with a recommendation rather than just a finding. If you can say, “Here is what the data shows, and here is what I think it means for the decision you are trying to make,” you contribute to the solution rather than complicating the picture. Leaders respond better to that, and it positions the data team as a thinking partner rather than a reporting function.
That said, genuine tension can exist between what leadership expects and what the data is showing. In those moments, the most productive thing you can do is understand where their expectation came from: what influenced it, what source it was based on, and whether it can be reconciled with what the data is telling you. More often than not, walking through the discrepancy carefully and showing where the misinterpretation occurred is enough to resolve the tension and rebuild confidence. And when there is no clean reconciliation, the right outcome is sometimes a middle ground: show both the reality and the context around the expectation, so leadership can see the full picture and make an informed call.
The hardest part isn’t the code
You write a query; it either returns the right result or it doesn’t. You build a pipeline; it either runs or it fails.
Technical work has a clear definition of right or wrong.
Communication doesn’t work that way. The same insight, delivered to two different people in the same room, can land completely differently depending on their context, their priorities, and what they already believe. That ambiguity is genuinely harder to navigate than most technical problems, and engineers are rarely trained for it.
Technical professionals also often conflate explaining their work with communicating an insight. Those are different things. One is about the process; the other is about the outcome, and what it means for the person sitting across from you. Business leaders don’t need to understand how you got there. They need to understand what it means and what they should do about it.
Simplicity without the spin
Lead with the “so what”, not the “how”. The instinct is to walk someone through your methodology to build credibility before landing the finding, but by the time you get to the point, you’ve already lost the room. Start with the what, then offer supporting context for those who want to go deeper.
Another thing that helps is anchoring complex ideas to decisions the stakeholder is already making. Abstract findings become concrete the moment they connect to something the person in front of you cares about. If you can say “this finding means you should do X differently”, you’ve communicated. If you can’t make that connection, you’ve only reported.
Lost in translation: technical vs communication failure
It’s easy to throw a statistic out here, but you’d probably be getting lied to with numbers. What can be said with confidence is that the scale tilts heavily away from technical causes. In Opeyemi’s experience, most project failures trace back to everything except the technology.
At the centre of most of those failures is communication, though not in the narrow sense of presenting findings clearly. Misaligned expectations between the data team and the business. Scope that was never properly defined or genuinely bought into by the right stakeholders. Findings that challenge leadership’s existing narrative, delivered without enough diplomatic framing to land. Stakeholder management, organisational dynamics, change management: all of it depends on communication working well at every layer.
Your analysis can be airtight and your solution technically sound, but if the communication infrastructure around the project is weak, the outcome will reflect that. That blind spot is one of the most expensive patterns in data teams across organisations.
From the top down: leadership and data-driven culture
Becoming data-driven is one of the holy grails of the industry, right alongside self-service analytics. Both are easy to put on a board deck. Both are extraordinarily difficult to achieve in practice, not because the technology isn’t there, but because the moving pieces extend far beyond technical problems: organisational politics, competing priorities, misaligned incentives, and the human dynamics of how people actually make decisions.
Companies often treat becoming data-driven as a destination rather than an operating discipline.
Organisations invest in tools, hire teams, build dashboards and check the box. But what has actually changed in how decisions get made? Usually very little. They’ve confused investment in data infrastructure with a cultural shift, and those are fundamentally different things.
In practice, it’s less about individual behaviours and more about systemic discipline. It means metrics are well defined, agreed upon across teams, and understood the same way by sales, finance and product. It means the data foundation is trusted enough that people act on what it shows, rather than building parallel spreadsheets to cross-check the dashboard. It means leadership doesn’t just consume data; it lets data change direction when the evidence points somewhere unexpected.
Most organisations I’ve worked with aren’t struggling because they lack data. They’re struggling because the overall system required to make that data usable, and to drive genuine adoption across the business, was never properly built. That is the work. If the solution isn’t being leveraged, it doesn’t matter how well it was engineered.
What senior leaders wish junior data professionals knew sooner
The technical work is the easier part of the job. Writing the SQL, building the pipeline, designing the dashboard: those are learnable skills with clear feedback loops. What takes much longer to develop, and what ultimately determines how far you go, is understanding the business well enough to know what’s worth building in the first place.
Early in his career, Opeyemi measured his value by the quality of what he built. Over time, he realised that the more important question was whether what he built actually changed how someone made a decision. A perfectly engineered dashboard that nobody uses isn’t a contribution. A rough analysis that shifts a leadership conversation is. That’s not to say professionals should neglect their technical fundamentals; they absolutely need them. But developing those skills shouldn’t come at the expense of everything else that determines whether the work actually lands.
What matters most when hiring for a world-class data team
- Curiosity about the business. People who genuinely want to understand how the organisation makes money, where it loses money, and what decisions drive the difference. Without curiosity, you get technically excellent data models that add no value.
- Judgment. The ability to look at a business problem and decide what’s worth building, which modelling approach fits, and what trade-offs are acceptable. Any AI tool can describe the difference between a star schema and an activity stream; choosing the right one requires understanding who is asking, what decisions they’re making, and how the data will be consumed.
- Comfort with ambiguity. The best data people don’t need perfectly scoped briefs. They can explain a finding to a CFO, collaborate with an engineer, and translate a product manager’s vague request into something concrete.
- A genuine knack for learning. The field moves fast enough that what made someone valuable two years ago may not be what makes them valuable today. Technical skills can be taught; a self-driven appetite for growth is much harder to instil.
Beyond the automation: what matters as AI takes over routine analysis
AI can write SQL, generate dashboards, and even explain data back to you in plain English. What it cannot do is decide how data should be modelled, determine which metric definition is correct when sales and finance disagree, or sit across from a stakeholder who says “the numbers feel off” and figure out what they actually mean.
This is not hypothetical. Earlier this year, McKinsey’s CEO shared that the firm now has 25,000 AI agents alongside 40,000 employees and expects to reach parity before year-end, with non-client-facing staff down 25% while output is 10% higher. Asked what skills matter in this next phase, he named three: aspiration, judgment and creativity. Not technical skills.
The skills growing in value sit above the execution layer. Domain knowledge is one: understanding how finance calculates gross margin, how product teams think about retention, how the business actually makes money. Communication is the other: as AI handles more of the production work, the ability to translate findings into decisions becomes the differentiator. Opeyemi built a five-layer roadmap for data professionals navigating this shift, and only one layer is technical. The other four are about thinking, communicating, understanding business context, and building relationships.
Deep technical expertise used to be the moat. AI is compressing that moat.
The dividing line going forward will not be your title, your years of experience, or how well you know the stack. It will be what your value is actually built on. The ones who remain indispensable can do what AI cannot: decide what is worth building, evaluate whether the output makes sense in context, and drive adoption across teams that don’t share their technical vocabulary.
