How Data People Can Bridge The Gap Between Data and Non-data Teams
Tips for data folks to build their side of the bridge — by community member and accomplished data practitioner, David Jayatillake
A lot of the talk about bridging the gap between data people and non-data people is centered around empowering non-data teams or adopting tools and solutions that bring the two camps together.
While this is a step in the right direction, it’s not enough from the point of view of an organization that truly wants to beat the gap.
is one of the few data professionals who has been vocal about this stuff which led me to asking him the following questions:Organizations also need to empower data teams to understand the business better — data folks need really need to understand the priorities, workflows, and constraints of non-data teams.
Why is now a good time for data folks to improve their non-technical skills?
Why is technical aptitude not enough to excel as a data practitioner?
Why do data teams need to understand the needs and priorities of non-data teams and learn to speak their language?
The answers, I believe, are particularly useful for data folks working at companies with mature data teams.
Let’s hear it from David!
Why is now a good time for data folks to improve their interpersonal skills?
Now is a good time for data people to improve their interpersonal skills as it always has been a good time to improve those skills — they’re as important as the technical side of things.
To understand the business and anticipate the needs of stakeholders — reading between the lines of what they’re saying, and asking a few drill-down whys when they ask for stuff (data) — acts as a force multiplier.
Just like having more technical ability is a force multiplier, so are these non-technical skills. Oftentimes, applying these skills massively reduces the time spent doing data work and improves the stakeholder’s perception of you.
Why is technical aptitude not enough to excel as a data practitioner?
It’s possible to excel as a data engineer (DE) who is assigned tasks by the product manager to build (data infrastructure) — such DEs may not need the highest level of business understanding and interpersonal skills.
However, business knowhow can certainly help DEs understand the context of what they are building. Sometimes they can spot what their PM has asked for as being problematic as they’re able to foresee technical issues in accomplishing the broader goal.
For other data roles, it is fundamentally impossible to do the role justice without understanding the business.
The Analytics Engineer builds a data model to represent how the business operates and that enables the business to measure metrics for decision making.
A great analytics engineer has a data DAG and a business DAG mapped out and knows how the two marry up.
The Data Analyst is the most obvious role where they interface with the business day-to-day to provide answers to questions.
Analysts have to understand the business goals as thoroughly as anyone else on the non-data side of the business.
Staff and Principal level analysts challenge their business to ask better questions and in the process, help them make the right decisions.
The Data Scientist (a term I use loosely to define data folks who build ML models to automatically make decisions for their business) must understand their business processes to a very high degree to even know where they can operate.
Data scientists need to be able to articulate business cases for projects they want to work on, and explain the benefits of what they’ve already deployed.
Why do data teams need to understand the priorities of non-data teams and learn to speak their language?
In order to partner with non-data teams and solve their problems using data rather than just fulfilling their requests.
Highly effective data teams are allowed to be part of the planning process in the business — they know what the business is trying to accomplish and aren’t just given a bunch of tasks without context.
When data teams work in this proactive manner, they are much more likely to do the right work the first time around. The work is going to be more fulfilling as it’s going to be end-to-end in context of the business objective.
In such cases, data teams aren’t just being asked to pull data for someone else to dice up in Excel and present findings…no analyst wants to do this.
The chances of the analysts being able to go deep and do more advanced analysis — which is very valuable and fulfilling — is much higher this way:
Data teams at medium to large orgs often have embedded data folks in teams like product, marketing and finance who are experts in these areas as it’s hard for one data person to be an expert in all of these domains. I do think a certain level of embedding is necessary for this specialist knowledge to be gained.
Data teams must learn about what impacts the bottom line and be able to communicate with business teams without technical jargon.
Data teams need to understand the business and it’s terminology and how that translates to data. For instance, it could be the CAC (Customer Acquisition Cost) and how it’s calculated from data, what the limitations in its associated dimensions are, etc.
Any other closing thoughts?
I don’t think it’s possible for data folks to know the business too well from the get-go; therefore, they should be devoting time to it.
Here are some things you can do throughout your time as a data person:
During onboarding, take the time to meet everybody and build a broad picture of the company and its org structure.
Continue to stay in touch with non-technical people and understand what the key priorities for the business are, in order to be more efficient, proactive, and impactful at every step.
As you progress or depart, ensure that the rest of your team is also being engaged in this way and help them if that’s not the case.
Let’s thank David for sharing his knowledge with us! 🙏
David also writes prolifically at and runs a Mastodon community for data folks. You can connect with him on LinkedIn too.
 | A guest post by
|