5 Tips To Improve Collaboration Between Data and Business Teams
How to nurture healthy stakeholder relationships in an international scale-up organization.
Motivation
Since the Spotify model was introduced in 2012, the tech industry has been adapting the ideas of Squads, Tribes, Chapters, Trios, and Alliances.
I have seen different adaptations of the Spotify model during my time in various Tech corporations. The first company pretty much followed through with the structure of Squads & Tribes for the official reporting line. Guilds were a bizarre bottom-up movement. All Guilds were formulated by driven individuals and operated on a voluntary basis. Take the Data Guild for example, it started with around 20–30 data talents meeting in a glass room irregularly. By the time I left, it had boosted up to a community having two internal meetups per month with 50–150 participants — and the Guild channel on Slack has around 500+ active members today.
The second company took a slightly different adaptation strategy. They used Squads & Tribes, however, they also used Alliances which were collections of more than one Tribe in the organization’s array. In addition, Chapters were also created to serve as a platform for data talents to share knowledge & best practices within their own function (e.g. Analytic Chapter, Data Engineering Chapter, Data Science Chapter, etc.).
While listening to those professional Data talents, the same set of struggles often come up from time to time: empty tickets created by stakeholders, requests without any specific details, ad-hoc requests coming in at the last minute, scope creeps, etc.
The collaboration between Data teams and their stakeholders (Business, Product, and Tech) is more an art than hard science. I figured that writing a tech blog post may be a beneficial way to bring in new angles for various Data teams and even stakeholders to have a more smooth collaboration — hence this article.
1. Have empathy
Empathy is the capacity to understand or feel what another person is experiencing from within their frame of reference, that is, the capacity to place oneself in another’s position.
- Bellet PS, Maloney MJ (October 1991). “The importance of empathy as an interviewing skill in medicine”
In plain language, empathy stands for the capacity to “put ourselves in another person’s shoes”.
The book The Culture Map, written by Erin Meyer, was quite a hit some years ago. It wasn’t a coincidence — instead, it caught people’s attention as it is getting more relevant than ever.
Being a France-based company, 60–70% of Vestiaire Collective’s employees are French. Nevertheless, it has already expanded to 70+ countries and has offices across Europe, APAC, and the Americas. In other words, our colleagues come from all around the world.
On top of different cultural backgrounds, the teams in Vestiaire Collective also have diverse expertise: Data, Product, Tech, etc. Even under the big umbrella of “Business”, there are also different domain functions: Marketing, Finance, Operations, Business Performance, and others.
Occupation drives certain ways of thinking. For example, Data and Tech teams always appreciate these elements whenever receiving requests:
- Clear Use Cases
- Specific details of the request
- Expected timeline
- Relevant documentations
On the other hand, Business teams are standing on the very frontline performing their duties and seeing a fairly different perspective. Their job is not always predictable due to the nature of business itself — sometimes life just happens! For them, the preference is always:
- Ad Hoc requests can be submitted whenever.
- Requests being delivered ASAP — it should have been done yesterday!
- Just tap the Data people’s shoulder and ask for it — it should be an easy task, 5 minutes tops!
To collaborate smoothly, both sides need to understand each other’s thinking and rationale. Data and Business teams ought to be partners. A partnership is a relationship — and a relationship takes commitment and sometimes compromise to keep it running healthy.
The 5th habit from the book The 7 Habits of Highly Effective People says it well: “Seek first to understand then to be understood”. We as human beings are given 2 ears and only 1 mouth for a good reason.
2. Plan ahead
If you fail to plan, you plan to fail.
- Martin Lassen
When it comes to collaboration between Data and Business teams, it is always a good idea to plan ahead.
Planning is essential for Business teams, sometimes even more so than for Data teams. The Business plan sets the tone, which helps the Data teams better understand where the value is and hence plan their tasks effectively. In other words, there is a dependency from Data teams on Business teams’ planning.
Likewise, the Data teams’ planning is vital for the Business teams as it gives them a better sense of expectation for the deliverables. Whether for quarterly roadmaps or sprint prioritization, planning is a necessary action to decide on priorities ahead of time. Why is it important? Because it saves time to think “if this task is important” and allows the teams to fully focus on delivery.
3. Document everything
It is pretty self-explanatory: putting information down in black and white helps iron out many potential issues.
First, documentation helps the teams double-check if they genuinely understand the business concepts, data concepts, or what is expected. They often think they comprehend everything before unexpected issues pop up once they actually get their hands on it.
Secondly, it provides a good source of information for future reference — which aids in planning and framing communications. Proper documentation also eases the difficulties of onboarding new joiners and non-specialist contributors. On top of that, it further enhances collaboration at both Business and Data teams levels.
The team I stayed with in the second company mentioned in the introduction went so far as to stand by the following principle: “If it was not documented, it didn’t happen.”. It might sound radical at first glance, but this policy worked reasonably well and the documentation there was well organized and linked to other internal and external resources. The team used the traffic going through their documentation as a KPI.
4. Communication
The book Talking to Each Other (German: Miteinander Reden) by Friedemann Schulz von Thun introduced this very interesting model:
Graphic of the four-sides model | Wikipedia
Communication is merely an information exchange between the Sender and the Receiver. And Schulz v. Thun also highlighted that there are four components in the message delivery flow:
- Factual Information
- Self-Revelation
- Relationship
- Appeal
Factual Information is merely sharing information. E.g., “Here is the ticket. It contains the content of what I need”.
Self-Revelation is the message the Sender wishes to express about themselves. E.g., “Hey, I know how to use JIRA. I know tech and data!”.
Relationship implies how the Sender perceives the Receiver and vice-versa, as well as how the Sender perceives the interaction. E.g., “I am your stakeholder in this ticket.”.
The Appeal is the request the Sender wishes to communicate to the Receiver. E.g., “Please work on this ticket ASAP!”.
When communicating, individuals also share a fair amount of information non-verbally. This is especially true for in-person conversations, as our bodies are message transmitters! Source: What Every BODY is Saying by Joe Navarro and Marvin Karlins.
Depending on their cultural background, people convey and receive messages differently. Using the graph from point 1 — Have empathy, we can see fairly significant differences in communication between the four countries in the graph, which is just a small sample of reality. For example, Germany has a low-context culture, while France has a high-context one. It implies that people with French backgrounds tend to expect the receiving end to decrypt the conveyed message from the context, while people with German backgrounds are expecting to get the message in a more explicit manner.
As a best practice, it is better to over-communicate and be specific and explicit rather than leaving too much room for interpretation — which is usually the cause of misunderstandings.
In addition, the relationship between the Sender and Receiver also plays an important role. As mentioned above, Data and Business teams are partners and should be equal. The communication should also express this relationship between both parties.
5. Recognize the inputs from each party
The famous physiologist Abraham Maslow has proposed the concept of human needs on 5 levels, namely “Maslow’s Hierarchy of Needs”.
In this theory, humans would start pursuing needs on the next level while their basic needs are satisfied. Recognition of one’s achievement falls in the 4th level of the pyramid: Esteem. Successful delivery of projects is seldom only one person’s or team’s effort. Instead, they are mostly the outcome of effective collaborations across multiple teams (Data and Business teams included). While the Data teams ought to understand the value brought to the table by the Business teams, the Business teams should also recognize the contribution of the Data team.
Recognition is a two-way street. There is a famous Chinese expression in Hong Kong: “一個巴掌拍不響”. It could be literally translated into “a person cannot clap with only one hand”. It takes only one of them, either the Business team or the Data team, to start recognizing the other side’s contribution. The momentum would start building and eventually lead to a virtuous circle of motivation — a vibe everyone likes and is happy to be part of.
Conclusion
Out of the 5 tips, the first one about empathy is the very foundation of all other pieces of advice. Having empathy, the Data and Business teams will:
- Plan ahead to let each other know what to expect.
- Build proper documentation for each other’s references.
- Make sure they understand each other.
- Recognize the contributions from different parties and celebrate success together.
