DevEx at DAZN: planning internal rotations and roadmapping

Note: Due to recording quality issues, this episode is not available in audio format. You can read the transcribed and lightly edited interview below. ‍

Tell us a little about your current role and the team you lead. 

Cirpo: I’m Alessandro — I go by Cirpo — and I’m the Head of Engineering for Developer Experience at DAZN, which is a sports streaming service. 

For context, we have over 2,400 employees at DAZN in 25 countries and around 700 people in engineering. Headquarters are in London but we have people in engineering in other countries, in Europe and Israel. And the Developer Experience (DX) team currently has 12 engineers. 

‍

Can you walk us through the origin story of your team? Why was it created? 

I joined DAZN four years ago when the engineering team wasn’t nearly as large as it is today. I joined a team called the Core team.

At DAZN we have the motto “you build it, you own it.” We’ve adopted the idea of having autonomous, empowered teams in order to build their services. The pros: in theory, teams move faster avoiding dependencies. But the challenges are the communication and coordination amongst teams, duplications (not always a bad thing per se), and cognitive load. The Core team, which became the DX team, initially focused on mitigating those challenges specifically with the frontend 

Over time we expanded our focus (and grew our team) to other departments like backend and full stack teams, aiming to expand to other areas like Mobile, Devices, and Testing.

“Every company has developer experience, but not every company has a developer experience team.”

‍

Could you describe the mission and purpose of your team? 

The DX’s team’s mission is to “empower every engineer to build the best products and reach their goals by providing the best tools in a supportive and responsive way.” 

I believe that DX is not a new thing, even though it’s an emerging topic in the past two-three years. DX has always been there, we are just giving a label. Every company has developer experience, but not every company has a developer experience team.

Sometimes “DX” can be confusing because there are internal and external-facing DX teams. Here’s how I break it down:

How I think about DX generally: “Developer Experience” in general is always at the front of the engineer’s mind as they do their daily work. 

External-facing DX teams are teams that work for external-facing developer products. These teams can be seen more like UX but applied to developer products as their users are developers.

And internal-facing DX teams are devoted to improving the efficiency of the company’s internal engineers. The engineers are our customers.

“The DX’s team’s mission is to “empower every engineer to build the best products and reach their goals by providing the best tools in a supportive and responsive way.”

‍

Before this call you mentioned onboarding as an area of focus, and just now you specifically spoke about providing tools to support engineers. I’d love to dig deeper into that: do you look at the process side of onboarding, or stick to focusing on the tooling? 

This ties into what we were talking about earlier, “you build it, you own it.” DX at DAZN is a support role. We don’t impose standards, we let them emerge.

Now, sometimes thinking about support, it seems like support means there’s a disaster to fix. But that’s not it for us. Support for us is a way of understanding the needs of your customers and helping them achieve their primary goals in the fastest, easiest, most friendly way possible. By “customers” I mean people in the engineering departments in our company. 

The DX team is not there to define how someone else should work. It’s more like “guidance over governance”, like the other teams in the Platform department. So regarding onboarding, we don’t decide how a team or department should do onboarding, because it might be different depending on the role, team or department. 

What we are doing is provide the foundational blocks of onboarding, things that need to be completed for every engineer. These could be either standard checklist items: getting a DAZN email, GitHub account, etc., or a specific onboarding path based on the role, team, and department. We provide those to engineering teams and they can then build on those items for their own onboarding plans. The important bit is that the tool is focused on collaboration: an onboarding journey can be copied, updated, and improved by other teams.

‍

Sometimes there’s this tension between product teams that are autonomous and independent and then support teams that want to come in and define standards or advocate for certain ways of working that the independent team isn’t used to. So how exactly has it looked for your team to work with the product engineering teams? 

One of the hard parts of a Developer Experience team is that your backlog could potentially be infinite. There are so many good ideas, but you have a fixed capacity. So the question is, between all these different ideas, which one do we  choose? 

For context, we typically have 2-3 projects in progress at any given time, with all DX team members working on all or most of those projects. We also work in 6-week cycles centered around high-level specifications (deliverables) that we call “bets”, inspired by “Shape up” from Basecamp. Our product owners define “bet” documents for what they propose we work on for each 6-week iteration. We discuss the bets and their potential impact as a team.

The way we decide “potential impact” is primarily through developer feedback: through surveys, their feedback on our chats, or informal discussions. 

Some tactical examples of how we work directly with engineers:

• We use working groups to collaborate and fix/resolve a specific challenge. We’ve used working groups to implement things like a progression framework, cross teams libraries, CI/CD specific features, and improving SLO adoption, for example. 
• We also have an “inner source model”. The DX team can’t own everything, otherwise we’d get locked into a reactive mode. So the inner source model is a way for all DAZN engineers to contribute to our internal tools using an internal “open source model”. 

‍

In terms of how you’ve built the team, how do you hire and find the right people to staff your team? And what are the skills people need to have to be successful in your DX team? 

The team had three founding members, myself as a manager, and two engineers. Now we’re 12. And I think something that’s interesting is we’ve only had one external hire during the past 4 years because the DX team uses the concept of rotation. Meaning, as an engineer at DAZN, you can join the DX team for a short period of time — a few weeks/months — if you’d like to experience something new, or if there’s a project we’re planning that you’re passionate about. Sometimes the engineers will decide to stay on the DX team, but that’s not the expectation.

At any given time, we usually have between 1-3 engineers rotated onto the DX team. There isn’t a set structure for what these people work on or how long they stay on the team. Reason is, sometimes we have more pressure from a delivery point of view, and sometimes a team member joins without a specific project in mind to focus on. 

As for what skill sets an engineer needs to be successful in a Developer Experience team: having a product mindset is critical. The rotation concept is helpful in that our team deeply understands the “customer” (DAZN engineers), but we need them to practice staying close to the customer for feedback, for understanding the context of a problem, and then for implementing a solution that’s adopted. 

“Having a product mindset is critical… We need them to practice staying close to the customer for feedback, for understanding the context of a problem, and then for implementing a solution that’s adopted.” 

‍

One of the challenges that other teams like yours struggle with is justifying and advocating for their existence, and getting funding. By comparison, your team is large. How have you been able to advocate for those resources? 

I think it helps that from the beginning we’ve always had a mindset of starting small, proving value, then growing. But it also helps that a big part of our role is focused on tools. We do things around culture too, but since we’re focused primarily on tools and processes, we can have a more direct impact on the engineers’ ability to deliver. 

So in short, starting small, being customer/product focus, and showing success metrics have helped justify further investment in our team and projects. 

We’d love to expand the DX team even more. But in order to do that we have to take it step by step. 

One more thing we haven’t touched on that’s related is our team’s values. One of the values is we “prefer data-driven decisions”. We say “prefer” because sometimes we don’t have enough data as things keep evolving. But the way we collect data is to be as close as possible with our customers, with the engineer. 

As an example, all the tools we build are connected to a service called RMS (rate my service), which is basically a pop-up that gets feedback on the tool. It asks the engineer to rate how satisfied they are with the tool, and then optionally provide more feedback. 

We check the feedback that comes in every Monday because sometimes the satisfaction can vary depending on the engineer’s time with the company (i.e., if they’re new), or if we’ve introduced new stuff on the service and it’s not as great anymore. 

But we can see how the feedback from the tools is changing, and report on progress. We can also survey developers on different aspects of their developer experience and see how those are trending. The comments from the surveys are usually where we find the best information on how to solve problems. 

And with the “bet model”, anyone can contribute to our backlog, suggesting bets.

The other metrics we look at to help justify our progress, are things like the time it takes for a new hire opening a GitHub account to their first pull request, to that pull request being merged. So we get “time savings” by looking at metrics like this, and then we can report on “friction” by looking at survey data and the like. We also rely on several data sources, like what are the main topics discussed in the DX support chat or a tool we build that collects meaningful data from all the DAZN repositories on Github.

‍

Wrap up

From my experience in the past 4 years setting up a DX function, I would suggest to start small, hire product/customer obsessed engineers, quick iterations, maximize engagement with your customers (the other engineers) and keep measuring.