Every few weeks, we see the same situation unfold.
A client comes to us looking for a “Data Engineer,” but after a short chat, it turns out what they really need is a BI Developer to rebuild their reporting model. Or they’re advertising for a “Data Analyst,” but the role description includes managing ETL pipelines and cloud infrastructure.
Across industries, the titles sound familiar, but the actual work varies wildly. The lines between business intelligence, analytics, data science, and engineering have become so blurred that even experienced hiring managers struggle to know where one role ends and another begins.
The blurred lines between data roles
Traditionally, each data role had a clear focus:
- Data Engineers built and maintained the plumbing - the pipelines, transformations, and storage that make data usable.
- BI Developers turned that data into insight through data models, dashboards, and reporting.
- Data Analysts focused on interpretation, identifying trends and helping people make decisions.
- Data Scientists took it further, using statistics and machine learning to predict outcomes.
But in practice, the boundaries have faded. A BI Developer today might be writing complex SQL or managing dataflows. Analysts are often stuck cleaning data instead of analysing it. Smaller organisations expect one person to do everything from data modelling to visualisation to stakeholder engagement. The result is a patchwork of overlapping skills and mismatched expectations.
Why this matters
When job titles don’t match the work, everyone feels it.
Companies struggle to fill roles because they’re chasing the wrong skillset. Candidates get frustrated when the job they signed up for isn’t the one they’re actually doing. And BI projects can stall when teams lack the right balance of engineering and analytical expertise.
We’ve seen teams with excellent analysts but no data engineer, spending hours manually refreshing spreadsheets every week. We’ve also seen well-built data warehouses that no one can interpret because there’s no BI resource translating it into business language. Both scenarios are common, and both cost time, energy, and money.
It’s not just about productivity. Misaligned roles make it more complicated for organisations to understand their own data maturity. Without clarity on who owns what, decision-making slows down, and the value of BI investment becomes harder to see.
Start with the problem, not the title
The best starting point is to step back from job titles altogether. Before deciding what role you need, define the problem you’re trying to solve.
Are you trying to automate manual reporting? Improve data quality? Integrate multiple systems? Each of those challenges points to a different mix of skills - and sometimes to a different order of priority. Hiring a data scientist won’t help if the data model underneath is broken. Likewise, a strong BI developer can only go so far without clean data or a clear business question to answer.
At DATAMetrics, we often help clients clarify this before they recruit or restructure. A short discovery session can quickly show whether the bottleneck is in data architecture, modelling, or reporting. Once the real issue is understood, it becomes much easier to decide whether you need a data engineer, a BI developer, or both.
Build overlap, not silos
The most effective BI environments aren’t built around rigid roles - they thrive on collaboration. Engineers, analysts, and BI developers each bring something different to the table, and the real value lies in the overlap of their skills.
When engineers understand reporting requirements, they design better data pipelines. When analysts know how the data is structured, they ask better questions. And when BI developers stay close to business users, they create dashboards that drive real decisions rather than just looking pretty.
Encouraging this overlap doesn’t mean blurring responsibilities further. It means creating shared understanding and open communication between the people who make data work.
A smarter way to resource data teams
There’s no single formula for how a data team should look. Some organisations need deep engineering expertise. Others get more value from a strong BI developer who can own both data modelling and visualisation.
What matters is fit - aligning skills to the business problem, not to what’s currently trending on LinkedIn.
If your “data engineer” is spending more time designing visuals than pipelines, or your “analyst” is buried in Power Query scripts, it might be time to rethink how roles are defined. The labels don’t matter nearly as much as whether the team has the right mix of capability to move from data to insight.
The takeaway
In the end, data success isn’t about job titles. It’s about outcomes.
Before hiring another “data person,” take a moment to ask what problem you’re really trying to solve. Once you know that, you can build the right mix of skills - whether that’s one specialist, a small blended team, or a partner who can help you design it.
At DATAMetrics, that’s where we start every project: understanding the challenge first, then shaping the right solution. Because getting the titles right matters a lot less than getting the results right.
