Lego Lego
Blog

Software engineering at DAZN

A jargon-free explainer for non-tech people

It doesn’t take much to confuse me. I sometimes find myself wondering - what is DAZN?! Are we a sports broadcaster? Are we a tech company? Well the answer is - we're actually a bit of both. We are a sports broadcaster but one that is built on amazing tech.

I run an internal speaker series via the live events function on Teams. The whole idea is to provide our people with a platform to raise awareness of the cool projects they are working on. It is a chance to reinforce the characteristics that we really value as part of our employer brand (ambitious, inventive, supportive, passionate and brave).

In a recent event I was joined by Cirpo Cinelli and Naomi Gaynor from our Developer Experience Team (DX). They helped deliver a jargon-free software engineering 101 to help non-tech people (like me!) get a better understanding for how our fantastic sports streaming service was developed.

I joined DAZN back in the summer of 2018. I had come from the football industry and was aware of the DAZN product. To me, it felt like a revolution - the missing link for fans. I couldn’t turn the opportunity down. I worked closely with tech and product people for my first year at the company. It suddenly became clear that not everyone here was motivated by sport. A significant chunk of our engineering community signed up because of the technologies we were using and the scale we are operating at.

Software engineering is part of the tech arm of our business. Tech at DAZN is split into four key parts - Programme, Product Engineering, Streaming and Platform. Programme are responsible for shaping the overall DAZN product. The teams within Product Engineering cover off living room devices, mobile devices, the web version of DAZN and growth (the acquisition and retention of customers). Streaming owns the overall playback experience and the delivery of content to the viewer. Platform is a centralised function and they support the efforts of everyone across our software engineering arm.

Our application has so many components. Cirpo presented a couple of brilliant analogies - using Lego (!!!) - to help illustrate what our approach is from an engineering perspective. Platform provide the foundation that everything is built on. There are also a bunch of background services that you don't see as a customer - they make up the back end. Then you have the customer-facing environment - the front end - which contains all the features that our subscribers interact with on a daily basis.

I learned about our approach to product engineering and the concept of micro-services. The original DAZN build was a monolith. One giant structure where all components are interlinked and interdependent.  A monolithic approach helps you validate a product or a concept. That’s exactly what DAZN did. They identified a gap in the market and quickly built a product in order to start delivering an amazing collection of sports rights. There came a point where we needed to grow. We needed to expand our product as our audience got bigger. It made sense to switch to a micro-services approach - an approach where the product is divided into a collection of individual component parts. Each component was owned by a separate team. This allowed us to move faster and get more value to our customers but in a way where teams worked independently without slowing each other down.

Naomi described why the challenges we face are attractive to engineers - we are solving problems that haven't been solved before. Moreover, every solution we come up with has to withstand the scale that we are operating at... and 'scale' can mean a bunch of things! We have over 4,000 repositories on GitHub - a platform where all of the DAZN code is stored. Scale could also be interpreted as the number of features and improvements that we deploy everyday or the number of concurrent users we have watching content on the product at a given time.

We have this ‘build it, own it, ship it’ ethos at DAZN. It’s an interesting concept. Simply put, once you build a feature, it becomes your baby - you’re responsible from the inception, building it, support and for the maintenance. You’re responsible for making sure that the feature is never broken for the end user. This doesn’t mean that it’s under constant surveillance but it does mean that you have a duty of care. That could mean making sure the necessary testing has taken place or that automated monitoring has been set up in order to notify a developer if something unexpected were to happen.

Outside of work I am a big believer in the power of community. This is also important to engineers - not just at DAZN but everywhere. This is the mantra of sharing knowledge, mentoring and making (some) code available publicly, for free (open source), so everyone can improve and learn together. If you make some code available to the wider community then everyone can contribute, review it and make it better. I love this mindset and wonder if it could be applied to other areas of our business.

In a world where competitive advantage is important, perhaps fighting our instincts and collaborating with our competitors could lead to a situation where everyone wins.