Leading Reportal & CUED

Taking over the team

When the team reorganised, the Product Owner and tech lead pair became an Engineering Manager and tech lead pair. I kept the product knowledge from the previous two years and took on the people and the delivery: six people across the back end and front end, a support desk, and a platform with one setup per customer. Some of what follows started in my last year as Product Owner, and became how the team worked once I was its manager.

Sprints, retros and support

• Two-week sprints. Backlog grooming, estimation and prioritisation with the Product Manager each had a fixed slot, so everyone knew when decisions were made.
• Retros every couple of weeks. Engineering, Operations and QA took part, and several of our working rules came out of them. I wrote about them in Engineering, Ops and Business on the same side.
• Support. I handled the support desk myself, 345 requests in all, so engineers could stay on sprint work.

Code standards and a tech debt vote

We agreed a short set of standards and applied them to every repository: Ruff for linting, pytest with a coverage target of 90%, nothing merged to main without a pull request, an approval and a passing build, and Cypress tests for the user flows.

To decide which tech debt to tackle first, I ran a team vote: everyone scored ten topics on urgency and importance. Continuous deployment for every repository and consistent linting came out on top, and became the plan, tracked repository by repository.

A cloud inventory

In January 2023, while I was still Product Owner, I started a spreadsheet of everything the department ran in the cloud: 107 Kubernetes namespaces, 97 MongoDB databases, 41 S3 buckets and around 50 Lambda functions. Each line got an owning team and a yes or no on whether it was still needed. I kept it up to date until May 2025, and several old databases were removed along the way.

Postmortems

Every outage got a written, blameless postmortem, and I followed up until the actions were done.

Some of the hardest weeks came from unclear priorities, with requests arriving through too many channels. Since then I agree priorities with stakeholders, through one line of communication, before sprint planning.

Keeping the platform current

• Moved every service to current versions of its core libraries.
• Standardised and reorganised the code repositories.
• Switched off the old first-version messaging.
• Set up shared Angular components for Reportal and BMAT's broadcast monitoring app.
• Continued unifying the per-customer services, so new customers could be set up faster.

Writing it down

Over these years I wrote most of the team's documentation: what each of the platform's core services does, every customer's setup and rules, the report and cue sheet formats, runbooks for common support tasks, and the sprint workflow.