Hello? Hey, everyone. I'm Raul, and this is Elin. We both work at Spotify. Today, we want
to share a story about how we view the Barix implementation platform by leveraging cross-police
disciplinary teams and breaking silos. Before we get started, how many times have you asked
yourself questions of such as if only they had talked to each other a bit more? If only
iOS and Android developers had sat down and went through the API design before implementing
that! [Laughter]. Or even if back-end developers had double-checked the schema with the client
developers. We also have those questions at Spotify. And, especially when it comes to
those systems that are developed in environments. For example, back in the engineers, design
and system hard to be used by mobile developers, and vice versa.
>> An example of such a system at Spotify was our old A/B testing system that we call
ABA, based on feature flagging, event logging on our clients and on our servers, and it
has a web page for setting up and analysing experiments. And it was built pretty exclusively
by back-end developers in a data infrastructure tribe. And what we notice is, as this system
grew over time, this team of back-end developers were making assumptions about how things like
how to set up feature flags, and how to run tests that didn't really work on the platforms
that ABA was supposed to support - in particular for mobile. And since we like running experiments
at Spotify, we realised we had to do something about this, and we decided to sit down and
rebuild our experimentation platform. And now, given that we have this system already
that made us go, if they would only talk to each other, we figured why not take everyone
and put them in the same team and have them work on it together. We put together a cross-disciplinary
team to solve this problem, so we made sure we had back-end engineers, data engineers,
web, mobile, you name it, to build a better system than ABA. And both me and Raul worked
on one of these teams as mobile engineers and we built something we called remote configuration.
Remote configuration was a replacement for the feature-flagging mechanism within the
previous system. It revolves around remotely configurable properties of aspects, our applications,
our servers, and by changing the values that those properties can have, it allowed us to
compare the effects that this had on our Spotify users and do experimentation. With that, we
learned a lot in working in this team, and we wanted to share some lessons and learning
about working in cross-disciplinary teams to build better software.
>> So, the first thing that we did was to leverage the power of common abstractions.
So, we start out by sketching the full system design, and then interface between the clients
and the back-end. Given the background of our engineers in the team, the only way we
could do that was by having common abstractions for the problem's scope so that we could communicate
efficiently without getting stuck on implementation details or some specifics of the disciplines.
White boarding and sketching design was important here for us, because it led us to share commonly
the same of what we were building together. We thought we needed to share discipline-specific
expertise. For example, one time, we found ourselves asking when and how we should update
the values for the configuration properties. Then we had the concept of secession, like
the abstract concept. Updating the s values mean that the UI wouldn't change while the
user was using our app. On mobile, the session was tied to the life cycle of the app. On
the web, they really didn't have a life cycle but they could see when the user was closing
or opening the web browser, or even when the web cookies were ex-paired. On the other hand,
for back-end, that was a bit different because you need to have a concept of a user life
cycle, but they did have a request, so then that is what you used. For us, a request was
a session, and that we had our common abstraction of the session that we could communicate around.
The second thing we learned was about learning and sharing, and growing together before there
are many differences between web, machine learning, back-end, mobile, and that affects
the way we work at engineers, and at Spotify, the back-end is played out in thousands of
microservices. Our mobile apps, they share huge monorepos, and more than 100 developers
working on the same monorepo. Also, back in microservices at Spotify, we can deploy them
worldwide in a matter of seconds, and our mobile apps we've then released in a weekly
cadence. >> And these are constraints that we need
to take into consideration when building out our software, and while we found the abstraction
that is we came up with very helpful to allow us to communicate across our platform boundaries,
also taking the time to really learn how we work differently, based on our different backgrounds,
also proved very, very useful. For instance, one of the main problems that we had with
the old ABA system was that feature flags weren't reusable, and that was fine for web
and back-end because they had control over how they deployed, and who were using what
version of their software. On mobile, if you messed up setting up a feature flag, that
would delay the experiments by weeks, because you would have to wait for a new mobile release,
and then people to actually start using that release. So, we learned from that, and then,
in the new system, we made sure that properties on the web were reusable so that we wouldn't
face this problem again. But then, we also knew that we wouldn't add that complexity
to back-end and web, because they didn't really need it. And last thing was that by finding
these common abstractions, and growing, and learning, and really learning to trust each
other within those teams, we could really utilise our shared expertise and build a great
product. Compared to the old ABA system, our new experimentation platform has really clear
separation of concerns, we have idiomatic solutions for things like remote configuration,
experimentation analysis, for data collection, et cetera. And we know all of these things
because we've managed to answer all of those, "Arcs, if they only had talked to each other,
problems that arose with the early ABA system." >> However, this wasn't all unicorns and magic
feeds. It - setting up the teams got - was really a hard work for us. And it took us
much longer than expected to release that platform. The first problem we had was to
ship that in a matter of months, but actually it took closer to one year. It took time to
learn and like the specifics of each platform, and how they are different from each other.
It also took us some time to understand that the developers were thinking about the same
problems, but on different ways, because they have different perspectives. It was only after
all of this time together that we really felt comfortable to make compromises and trade-offs
between disciplines. It took strong technical leadership and guidance to make it through
comfortably, and to trust each other, and also to trust the product that we were building
together. >> Also, the truth is, having cross disciplinary
teams doesn't work for everything. Infrastructure in particular is one of those things where
you're dealing with problems that only face back-end developers, or only face web developers.
Both me and Raul work on mobile infrastructure teams and only solving problems for mobile
developers, but one of the things that we took back from this experience and this other
team we worked on, that it wasn't really the power of the cross-disciplinary team that
allowed us to be successful, it was the fact that we had a diverse set of perspectives
on the same problem that we were facing, and that we were solving more of the problem for
more people. And the practices that we've talked about, having common abstractions,
whiteboarding and visualisation, that allowed us to understand each other, and talk in a
language that we all understood. Learning and growing together meant that we felt safe
to share our different idea, knowing that we would listen to each other and incorporate
all of the learning into our new platform. So, really this wasn't actually a story about
how cross disciplinary team in particular bit a great product, but how we had a diverse
team, and allowing that diverse team and those diverse perspectives to really impact the
product that we were building made us build great software together. Thank you!