Belting out the chorus: engineering and design for graph machine learning in a distributed, multidisciplinary team
Written by Maria Wikstrom, Nhung Nguyen and Xavier Ho.
Have you ever heard the story of The Bremen Town Musicians? A donkey, dog, cat and rooster, all at the end of their prime, abandon their sad fate on the farm to pursue life as musicians in Bremen. Weary from travel, they discover a house inhabited by robbers. The four animals balance on each other’s backs and shrieking together into the darkness, terrify the robbers driving them from the house.
Like every good fairy tale, they live in the house happily ever after.
It’s a story of fraternity and collaboration. On her own, the cat can only meow. But with the dog’s bark, the donkey’s bray and the rooster’s crow, their chorus is commanding.
We too have story of fraternity and collaboration. The StellarGraph visualisation team are a multidisciplinary bunch comprising engineers, product owners and user experience/user interface (UX/UI) designers linking machine learning and distributed platform to deliver a graph visualisation product to end users. We’re also geographically distributed across three Australian cities.
The team is in a start-up phase and uses agile development methodologies. But, agile incorporates principles like daily stand-ups; difficult considering in some cases, we’re separated by 877.6 kilometres.
In this article we’ll discuss three key challenges of working effectively in a distributed, multidisciplinary team:
- Different disciplines; different motivations
- Mastering communication
- Creating shared understanding.
We’ll then explore the techniques we’ve found effective to manage these challenges to maintain alignment, sustain fraternity and ultimately develop a product that not only works, but actually delivers on what our users need.
| The first challenge |
Different disciplines; different motivations
Having the same background and skill-set creates ease through a common language and understanding. Multi-disciplinary teams on the other hand have a different set of benefits, like dynamic collaboration and outcomes.
The challenge in this instance lies in finding a way to manage the disconnect caused by different motivations.
In the context of our team, we could generalise that:
- our engineers want to build things in an efficient and scalable way;
- our designers want to solve problems holistically; and
- our product owners want to ship and iterate quickly.
How we tackle it
Trust and appreciate each other’s roles
As a group of experts in a multidisciplinary setting, we need to understand what each other does and the boundaries of these roles. We’ve found a good test is to answer the following questions about each other:
- What’s your role? What are you trying to do?
- How does your role fit into the team? What’s the bigger picture?
- How does your role impact mine, and vice-versa?
- What are your biggest concerns? Are there ways I could help?
Understanding also builds trust. Not only do we value each other’s talent and deep knowledge in our given disciplines, but we trust that we can voice our opinions and ideas even in fields we’re not familiar with.
“It means someone who cannot code like me can still have a good healthy debate and raise questions about a development approach,” says Nhung, StellarGraph’s UX designer.
“But also, good design ideas can come from developers and product managers too.”
Review each other’s work, and seek feedback
StellarGraph technical lead Xavier believes multidisciplinary teams should not only encourage and proactively seek feedback from each other, but that this feedback should be requested with a purpose.
“It’s daring to ask your team members; ‘How could I have dealt with that better? Or; ‘Do you have any advice on how I can improve that for next time? We are often afraid to show our weaknesses and fear the response we might get.
But by asking for feedback (and implementing it) we are communicating that we value the other person’s opinion and that we are willing to change our approach for the best possible outcome.”
In our experience, inviting contribution from others in multidisciplinary settings and incorporating this feedback into our work is not only healthy practice that achieves optimal outcomes, but makes for a better team dynamic overall.
Focus on the why
It’s generally safe to assume that other disciplines think about and approach problems differently to the way you might in your discipline.
Our rule of thumb is that proposing an idea or concept should be backed up with a clear rationale. What different iterations did you try? What worked, or didn’t work? Why is this new approach worth exploring?
Similarly, when offering feedback, we try to be precise about why something doesn’t work, why it could be a problem, and what could work as an alternative.
It’s also important to be open to the fact that different disciplines may have a different opinion of what’s working, and what’s not!
| The second challenge |
Mastering communication in a distributed team
Water-cooler conversations. They’re one of the most valuable ways for teams to connect, and one of the benefits most missed in distributed teams.
Whether or not they actually happen around a water-cooler, they’re the conversations that sit on the periphery of the work at hand and help the team learn more about each other; their tendencies, their joys, their frustrations, their life outside of work. They’re the conversations that forge trusting, personal relationships between team members and in that context, create strong teams.
It’s difficult to create (or replace) this culture in a distributed team. It most definitely requires effort.
Many things are naturally taken for granted when teams work in the same office. You can see if someone is not physically there, or running between meetings. You can see if a colleague is struggling with the pressure of workload and either needs support, or uninterrupted focus.
When working in a distributed team we have to plan for opportunities to communicate. And doing this effectively is a mighty challenge.
How we tackle it
Find a way to reiterate office discussions so everyone feels included
Several members of our distributed team are located together in the same location in their respective cities. Naturally, this means there are discussions and solutions taking place in person between those team members.
We use collaboration hub Slack to summarise these conversations and outcomes so the whole team has exposure. In the name of alignment, inclusion and general functionality, this is an imperative practice for our team and we’ve become disciplined at delivering on it.
This practice becomes more challenging when the majority of a team is based in the same location, with only few based remotely. But in this case it’s equally (if not more) important.
Stand-up and be counted
“Congregating around a white-board for stand-ups is tricky in a distributed team!” says Xavier.
“But stand-ups are fundamentally part of the agile methodology. The fact that our team is distributed makes the concept of stand-ups even more crucial.”
Distributed teams don’t have eyes on what each other are doing, making it difficult to have awareness of people’s capacity (or otherwise). There’s also an increased risk of doubling-up on work.
Our team enables daily morning stand-ups virtually, using Slack. This is quick and efficient; a few dot-points outlining the tasks we will focus on that day, and a mention of potential blockers. This brings focus to the team and keeps us on task.
Improve the future by looking back
Retrospectives are built into our workflow. We schedule a retrospective after every sprint, and also after major six-monthly delivery milestones.
“If there’s only one agile ritual to keep, for me it would be retros,” says Nhung.
I think it’s healthy practice for the whole team to honestly reflect after each sprint on what went well, what could be improved in the way we work, and outline the actions to take for the next time.”
For us retrospectives serve not only as a high-level team-building exercise, but to harness product vision. The process allows us to identify gaps and we take steps to close these gaps every sprint.
But retrospectives only work if individuals trust the team, and the process. Problems need to be called out and addressed without resentment or animosity.
If it doesn’t work, change it.
We have a team culture that prescribes no process be set in stone. So, if it’s not making our distributed team feel more connected and aligned, we look for other ways.
We have to be open to constantly reviewing the way we work, and try new approaches if there’s a promise of greater efficiency and team satisfaction.
| The third challenge |
Creating a shared understanding
We’ve all walked out of a meeting and reflected on the outcomes with a colleague only to discover we’ve heard completely different things. Different perspectives lead to different experiences.
There’s an old Indian story about a group of blind men who have never come across an elephant. As each man touches different parts of the elephant’s body, they describe the elephant based on their own experience.
The man touching the elephant’s tail believes it resembles a rope; the man touching the elephant’s tusk imagines a spear; while the man touching the elephant’s leg describes it as a tree trunk.
Any team — multidisciplinary or not — can likely relate to this story. In our case, when discussing an issue or feature using a generic term like ‘export feature’, we each have an understanding of how that export feature should look. Trouble is, our different perspectives mean we’re probably imagining different ways of implementing it.
A strength in multidisciplinary teams is that we think differently and have different ideas. But when going into delivery mode, we need a shared understanding of what we are building.
The first step to addressing this challenge is to be aware of it.
How we tackle it
Create alignment
When our team first formed, we defined the product we wanted to build by creating user stories.
User stories worked well for straightforward features. But we found for more complicated features with dependencies on other products, we needed agreement on the requirements of the feature before starting development.
So we started creating requirements documents to complement our user stories. These documents outline the feature requirements to be fulfilled, and specify any assumptions and elements that sit out of scope. In line with agile methodology, we’re careful not to present fully fleshed-out requirements since they’re assumed to be frequently changing.
The requirements document also supports iterative development by defining the bare-bones solution that we can present to users to validate that we are on the right track.
To learn more about the power of storytelling and user testing in shaping machine learning models, this article offers great insight:
The v.1 mindset
We have high ambitions for our product. We started out defining high-level epics like ‘implement advanced search’, but in the name of building the optimum product, found ourselves bogged down in implementing all the possibilities of doing advanced search: inclusive and exclusive searches, exact and fuzzy matches — it’s endless.
StellarGraph product owner Maria explains the principle in action:
“We agreed we had to implement the v.1 mindset to quarantine the scope-creep and focus on building basic functionality first.
For each feature we spell out what v.1 functionality should fulfil and explicitly state what is planned for implementation in the future. We then allow this first implementation (and user testing) to inform the next iteration.”
It’s not just on the product owner to cut scope either; the team are all encouraged to make suggestions on splitting the functionality into smaller iterations.
Agree on the problem before the solution
“As humans, we seem to be individually attached to solutions,” says Maria.
But by focusing on the problem first, we are forced to step into the shoes of our user which removes the personal element and leads us to solutions that actually deliver on what’s needed.”
In our experience, problem ownership has been the best approach here. A team member is assigned to the problem with the task of breaking it down and better defining it before work begins on solution delivery.
Typically this task falls to the product owner, but anyone with a solid understanding of their users’ needs and problems can take on problem ownership. This is the surest way to build a solution that truly resonates with the people who are going to use it.
It’s only once the problem owner has worked through the problem that the rest of the team gets involved. Even still, it’s often easier to agree on the problem than the solution!
This brings us to our final point.
Disagree, and commit
“We work towards a common goal: building a useful product that people love. This doesn’t mean we always agree on how to get there,” says Nhung.
Disagreement is natural and (most often) healthy in a multidisciplinary team. In some cases it’s inevitable you’ll lose the battle, but what’s key is committing to and trusting in the final decision made by the team..
It’s about finding balance between voicing your opinion — because diversity of thought is crucial for high performing, collaborative and inclusive teams — and maintaining team unison.
The moral of the story
While we’ll continue arguing about which one of us is the ass of our story, we’re not questioning how impactful we can be as a team of multidisciplinary experts, nor the quality of the solutions we’re developing in the graph analytics space.
We’re also not professing to have mastered the art of working in a distributed, multidisciplinary team. What could we do better? Or differently?
These are the ingredients that work for us:
- Walk the journey together. Tame tensions with trust and inclusion.
- Embrace asynchronous collaboration. Distributed teams need tools to support communication.
- Facilitate problem ownership. Nebulous problems require clear ownership to be solved effectively.
- Commit to improving the way we work. Aligning the team takes time and attention.
Above all, empathise with each others’ knowledge, needs, and motivations. And be confident in your contribution to the collective shriek.
This work is supported by CSIRO’s Data61, Australia’s leading digital research network.
