How To Organise Your Machine Learning Teams For Success

The three organization forms Uber, Linkedin and AirBnb explored to integrate machine learning into the organization

Functional, central, or hybrid team org? Image by the author.

Uber, LinkedIn, and Airbnb all are massive machine learning success stories, not because they produce cool research or got lots of talent, but because they actually manage to turn data into money, and lots of it.

All three companies spent years exploring different ways of organizing machine learning work.

I’d like to share the key insights that I took away from their efforts, so you don’t have to spend years exploring different models.

Three Ways to Organize Machine Learning Work

There are really just three ways of organizing machine learning work, and all three have strengths & weaknesses that can either put your machine learning engineers out of work or make them the most valuable asset you have.

So let’s take a look at the three different ways: functionally — within one large machine learning or data science or analytics function, decentralized — within a product/ engineering team, or a mixed form of both.

Functionally organized machine learning work might involve an analytics department with a dozen data scientists, or a couple of machine learning teams producing APIs. Decentralized machine learning work might integrate machine learning engineers straight into product engineering teams or it might put a machine learning team together with its product team beneath one single product manager.

Companies usually start with the central, functional approach, and often fail with it. Some manage to transition to a decentralized or mixed model, and some simply cut off the losses, and a few lucky stays with it.

So let us start with an example of a working functional model!

The Functional Data Science Teams at AirBnB & Uber

Even though many companies move away from a functional, central model, the company Uber still employs one even after years of machine learning. So I find it very useful to take a look at them.

Uber has a large staff of machine learning engineers, data scientists et. al. They organize parts of them functionally, in a large team context with only machine learning engineers & data scientists. If a product engineering team needs something they cannot do, which needs machine learning/ data science expertise, the product engineering team can collaborate with expert machine learners & data scientists for a fixed duration, for instance, a three month period.

Collaboration, e.g. project-based, between two functionally organized units, engineering, and machine learning. Image by the author.

This model has a bunch of key strengths, first, it minimizes the idle time of the data science/ machine learning function in the company. This in turn means companies can kick off such a function extremely early. Airbnb for instance hired a data scientist as its 8th engineer and used a central model for distributing the work for quite some time after.

Second, it maximizes knowledge sharing across the function, thus allowing a depth of knowledge to be developed, standards to be set, a shared tech stack to be created. All of this minimizes the time to value the function needs.

Companies who choose to employ such an organization form thus aim to unleash these strengths by employing a shared tech stack, regular workshops & lots of knowledge sharing tools across the function, and distribute the workload across the function by one central product manager. They have clear boundaries on the collaboration with engineering teams like “3-month projects” and hand over the code, ownership & expertise if reasonable as so as not to create coupling.

The Decentralised Approach at LinkedIn

The company LinkedIn also started out with a central model, one functional team of what I’d call “data scientists” with the aim to “create something great”, by developing cool things for other teams.

But they soon realized this wasn’t working at LinkedIn. To quote DJ Patil, formerly Linkedin: “those guys [, the data scientists,] come up with great ideas, show numbers, then get told this is not on the [product team] roadmap…”

They would prototype a “recommendation engine”, shows great numbers, but couldn’t get an engineering team to team up and build a frontend for it. The solution? They moved to a decentralized model, a full-stack team. They made them into a full product team that went on to create PYMK, Who Viewed my Profile, Skills, and the Career Explorer. The group included design, web, product marketing, engineering, and the PYMK feature became one of the most successful products a LinkedIn team ever created boosting Linkedin’s north star metric by 50%.

“The result of building a data team is, paradoxically, that you see data products being built in all parts of the company. When the company sees what can be created with data, when it sees the power of being data enabled, you’ll see data products appearing everywhere. That’s how you know when you’ve won.” (DJ Patil)

Strong full-stack decentralized teams, integrating machine learning engineers into the teams that need them. Image by the author.

Spotify employed this model from the very beginning, integrating machine learning engineers in the teams working on the products. The machine learning engineers working on the Spotify Weekly sit in the same unit that also creates the frontend, making them fully empowered on this product.

The first strength of this model is the concentration of product ownership. This results in a fast cycle time. Taking a new machine learning idea to production takes just as long as it would take adding a new drop-down option. No need to consolidate roadmaps of different teams. This of course unleashes the true potential of machine learning since it’s really the only thing that allows experimentation, which is almost impossible in a collaboration context.

Ever tried to convince another team to build a front-end feature so you can run an “experiment” and possibly kill the frontend feature again?

The second strength is the concentration of product knowledge. Machine learners and frontend developers participate in all team events alike and get all the knowledge they need to deliver the right thing at great speed.

The Mixed Model at Uber and Research

Uber, while being a great case for a working functional unit, actually has a mixed model. But what Uber recognizes is that a clear separation is needed between machine learning engineers in teams, expert machine learning engineers & data scientists working on a project basis, and a research team which purpose is to deliver company relevant research.

The strengths of the mixed model are apparent from the strengths of the individual models. It comes with all the strengths, but adds a lot of overhead in organization and communication. It is thus most suited for larger functions or heterogeneous requirements on the engineering side.

A hybrid model mixing full-stack teams, project expertise collabs, and research teams. Image by the author.

If a company has 1–2 product teams with lots of machine learning requirements, and 20 others with some requirements, then a mixed model might make sense.

Companies aiming at mixed models try to mitigate possible weaknesses by for instance developing common machine learning frameworks like Uber did with Ludwig. And converge on technologies like Spotify did by converging all machine learning efforts on TFX and Kubeflow Pipelines.

Don’t Play To The Weaknesses

AI, machine learning, data science are all hot new trends, but the only thing that counts at the end is turning this new stuff into business value.

Airbnb is deeply data-driven and always tries to maximize the business value of their data. Airbnb also recognizes the weaknesses of a functional data science organization. They realized that a central function lacks both the product expertise & the engineering skills of product engineering teams. So they created an education format for their data scientists empowering them to build up both skills.

Choose the wrong model for your company and your efforts will waste money, and eventually shut down the efforts. Choose the right model, unleash the strengths of a model instead of playing to its weaknesses, and you will be able to integrate machine learning & data science deep into the company, far beyond the analytics function.