DAZN Engineering
Published in

DAZN Engineering

Platform Engineering

Building A DX Team: Lessons Learned

A reflection on 2 years being part of a growing Developer Experience team, the successes, and the challenges.

Scaling The Ownership Of Tooling.

Ownership is an important topic within software engineering because when we get ownership right, it has been shown to directly affect the impact that our teams can have. And when wrong, the structure can become a source of frustration and angst.

The DAZN Inner-source Marketplace
The DX Repo Template Project

Developer Experience Is Built Around Strong Opinions

Something that I’ve observed over time, is that Developer Experience is built around strong (technical) opinions. When we create a new tool or start a new project, the tool is almost always built on top of either an implicit or explicit set of opinions. This point is relevant because the impact that a DX can have is intrinsically tied to the ability to make, and communicate technical standards and decisions.

An example RFC for our .dazn-manifest.yml file

How Does DX Choose What To Work On?

A very frequent question we get asked is about how we prioritise our work and choose the most important projects to work on. This topic covers a few different areas: firstly, how we generate, gather, and make sense of feedback, and then how we measure the effectiveness of what we have done or are choosing to do.

Results from the survey question “Our CI pipelines are slow”

How Do You Measure A Developer Experience Team Effectiveness?

It’s important to us that we can quantify the impacts we’re having. Success metrics help us to justify further investment in our projects and help us to manage our priorities. One of our DX team values is even “prefer data-driven decisions”.

Dashboard showing metrics on GitHub Actions migration.
Exported data tables in our database

Should A DX Team Be All Engineers?

Another factor that we think has been part of any successes we have been lucky to have, is by having an engineering-led team. We made the decision in the early days to try and avoid diluting our team with additional members like product, etc. Opting to try and manage with a team of purely engineers. This comes from a belief that the more knowledge, and empathy towards fellow engineers you can embody in your DX team, the better.

Building A Tooling Foundation

When the DX team is not responding to engineer feedback or requests, we are actively working on building on and extending our tooling foundation. We work to fill any gaps and make sure that our engineers have tools at every step of the way through the software development lifecycle.

The help page of DAZN CLI (showing just some of the commands).

What Was The Biggest Lesson Learned?

Original Twitter thread asking for input for this article.

So, Are You Building Your Own DX Team?

So there you have it! 2 years of learning and experience from growing our Developer Experience team. We’re not finished yet, but we hope that you can learn from some of our experiences. Here’s a short summary of some of our main takeaways from over these last two years for others who might want to start a DX team:

  • Drive community contributions to scale DX efforts
  • Engage actively in any technical-decision making processes
  • Rely heavily on GitHub (or source-control) data for success metric
  • At first, use project-based (instead of company-wide) success metrics
  • Find or recruit engineers who care about “product” as well as code
  • Build tools that interact across the whole development cycle
  • It’s always about people

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store