Belting out the chorus: engineering and design for graph machine learning in a distributed, multidisciplinary team
By: S T E L L A R G R A P H
Tags: Machine Learning, Data Science, UI, Graph Analytics, UX

| 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.

By Illustrator unknown — From Charles Maurice Stebbins & Mary H. Coolidge, Golden Treasury Readers: Primer, American Book Co. (New York), p. 89., Public Domain, https://commons.wikimedia.org/w/index.php?curid=4581171

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.

Tame tensions with trust and inclusion. Embrace asynchronous collaboration. Distributed teams need tools to support communication.

Distributed teams need tools to support communication. Facilitate problem ownership. Nebulous problems require clear ownership to be solved effectively.

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.