Advice to my future Tech Lead self
It’s so easy to go full steam ahead on new projects and not take the time to reflect on previous ones
I joined my first NHS England team as a developer last July, becoming part of the Invite team within Digital Transformation of Screening. After almost 10 years working on civic tech in different forms, I was excited to work for the NHS and dive into a new domain I knew virtually nothing about. There were a few themes that really stood out to me on the project, around communicating the narrative of a service, sharing knowledge and working towards a shared vision.
I’m starting a new team within Screening as a Tech Lead this year, and I know it’s so easy to go full steam ahead on new projects and not take the time to reflect on previous ones. So I wanted to write up a few notes for my future self.
About the project
The Invite Team was set up within Digital Screening to look at transitioning Breast Screening Offices (BSOs) from paper letters to digital-first communications with NHS Notify.
BSOs are specialised clinics, often within hospitals or mobile units, dedicated to performing mammograms to detect breast cancer early in eligible participants (typically 50-70). The processes across the country and between individual BSOs vary depending on the size and needs of the community they serve.
When participants are identified as qualifying for an appointment at a BSO, an appointment is booked in for them by BSO staff using a piece of software called NBSS (National Breast Screening Service) and a paper letter is generated and sent.
The specific goal when I joined the team was to deliver a small Private Beta-sized slice and work with one BSO, in Birmingham, to start sending NHS Notify invitations for a subset of their participants (e.g. those with low risk and invited for their first appointments).
The Private Beta rollout finished in December and the decision was made to move digital communications into the new digital screening service currently in development, rather than try to integrate with NBSS.
1. The power of communicating user-centred design
The architecture of the service was designed to take in a stream of event data and validate it, transform it, save it and trigger more events based on it. This was the first ‘headless’ service I’ve worked on, where there would be no frontend (except for the ones out of our control in NBSS, and NHS Notify).
This was being accomplished by Django commands that would run asynchronous Container App Jobs in Azure. Events would be triggered in NBSS, sent to a MESH Inbox (a type of medical messaging service), and then passed through various commands through to NHS Notify. Then, an email, text or letter would be sent to participants.
Because we had no user interface (UI) to take the team or stakeholders through, I think it made it harder to open up opportunities for collaboration and refactoring. Having empathy with a user filling in a form, for instance, is so much easier than trying to understand logic gates a piece of data has to go through. There was a need in the technical team to observe what the code was doing, for which we built a mix of custom and out-of-the-box tooling. But there was also a need to communicate the service to non-technical users.
My key takeaway from working on this architecture was how important user centred design is for any service, headless or not, to turn it from something abstract and remote into a real and understandable thing. We still had users, and we still had user needs. Keeping those user needs and real life impact at the forefront of our communication helped to keep the team on board and stakeholders engaged. It meant including dummy data reflecting real scenarios and edge cases, thinking carefully about the diagrams and artefacts we were using to describe the service, and zooming out of the intricacies of code in order to tell a broader story about the service.
2. Write the docs as you go
As I’ve gained more experience in lead roles, I’ve spent less time thinking about the small inner parts of the code we’re building, to thinking on a systems level about the different parts of the service and its users. I’m really interested in designing architecture and building tech not just for the end users of a service but also for the team, internal stakeholders and future devs.
This means building good monitoring tools, technical documentation and team health are just as important as building the service itself.
One of the tasks I had that really helped was creating a Support Runbook – – we saw it as a sort of bible for the project that could hold all the questions I had about the service when I first joined. Questions like: “What’s the project’s architecture?”, “How do I release to production?”, “How do I debug an issue?”, “How could I recover data?” are great prompts to start getting to know a system and to implement good practices of software development.
As the project went on, I incorporated more and more ‘How to’s’, including the jobs I had to do regularly or intermittently. These were things like: how to exec into a container, how to add environment variables, or a beginner’s guide to changing Terraform. And I would regularly look back at them myself as a reminder of how to do something. It became more like a wiki on the technical aspects of the project.
As I started to build out monitoring and alerting tools, there was a steep learning curve with the Azure portal UI and its Application Insights tool–a lot of which couldn’t be documented in code at all–so I took regular screenshots and high level notes on the tooling with the view of future devs needing to do the same thing.
Because I’d taken an approach of starting it early, and adding little and often, it never felt like a huge chore to do, and by the end of the project I think I could have handed it off to another dev without any other info. On my new team I’m very likely to need the same docs in a few months, so I’m looking forward to referring back to them myself!
3. The NHS is amazing
This was my first project working with the NHS, and I think there’s a course load of content on the domain-specific knowledge needed to understand the different pathways within Digital Screening alone. I’m still very much at the beginning of my journey, and learning so much from the incredibly knowledgeable and talented colleagues who are working so hard to deliver these life-saving services.
One thing that really stood out to me is the care taken over the risks we expose participants to, both on a systemic level and on an individual level, everyone I’ve worked with has had safety and inclusion at the forefront of their mind.
On a professional level, these opportunities and complexities make it such an exciting place to work, as there’s so much to learn and so many problems to solve. On a personal level, having had people close to me affected by breast cancer, it’s such a good feeling to know that all of our hard work has a clear goal we are all aiming for.
What the future holds
I’m really excited to be stepping up to Tech Lead for the new Cohort to Clinic team – we’re looking more broadly at the journey between identifying participants to be screened and inviting them to the clinic.
There’s plenty of challenges that go along with working in such a complex environment, but returning to the core principles of why we are building what we’re building means I’m looking forward to logging on every day.