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.