All work

Cue 05, 2026 to now

DSP Processing & Reporting

Since May 2026 I've managed the engineering teams behind DSP Processing and DSP Reporting: ten people at the payment end of the chain, where streaming usage becomes claims and royalty distributions.

Role
Engineering Manager, Rights & Royalties, 10 people
Stage
Claim & pay
Stack
Python, AWS, Kubernetes, Sentry, Jira, Confluence

What the teams build

Streaming services send monthly sales reports listing every track played. Two products turn those reports into money for rights holders:

  • DSP Processing works for collecting societies and publishers. It ingests and validates the sales reports, matches each line to the musical work and its owners, and produces claims and the files that feed royalty distribution.
  • DSP Reporting works for the streaming services themselves. It produces the usage reports each licensor needs in the industry's standard formats, and reconciles the claims that come back.

Both run at large scale and to deadlines, and a mistake in a file can hold up money for a lot of people.

The first months

I joined Rights & Royalties in May 2026. My first months went into learning how the two products work and writing it down where the whole team can find it. I wrote about that in You can only fix what you can see.

A two-week rhythm

The teams moved from one-week to two-week sprints, which means fewer meetings, more time to prepare each task and no end-of-week rush to merge. Velocity per week went up too. Planning takes the last two days of each sprint and ends in one meeting where Engineering, Operations and Business settle the scope together. I describe the full rhythm in From firefighting to a rhythm.

There is no release day. Changes go out when they're ready.

Support and incidents

Support runs on a weekly rotation, and I wrote the incident process the teams use. Both are described in From firefighting to a rhythm.