Becoming a Technical Leader without the title

The Benchmarking Network supports healthcare benchmarking across the NHS and wider UK healthcare system. The organisation's technical estate carries a high operational burden: millions of data records, active users who depend on reliable analytics, and a requirement for strong data integrity and service continuity. When I joined in July 2024, the engineering team was building a new generation of the Benchmarker product while managing legacy constraints, manual delivery friction, uneven development practices, tightly coupled application and data concerns, and growing demand from internal users.

I led a connected programme of technical and organisational improvement. I helped define the architecture of the new Benchmarker product, introduced modern backend patterns and engineering safeguards, established automated CI/CD and version-control standards, designed a resilient cloud-native data migration pipeline, and created a practical change roadmap for improving developer productivity and reducing organisational brittleness.

The work produced measurable impact:

• Release time was reduced by 75 percent through a robust CI/CD pipeline.
• A mission-critical migration of millions of healthcare records achieved 100 percent data integrity and zero downtime across UK datasets.
• Pull requests gained automated build, lint, and test feedback in GitLab.
• Dockerised services created consistent runtimes across development, staging, and production.
• Shared standards for pre-commit checks, code review, branching, semantic versioning, and release tagging reduced delivery friction and gave engineers clearer ways of working.
• The team gained an explicit architecture and capability roadmap covering API design, analytical workloads, developer experience, observability, testing, and self-service environments.

The most important result was a shift in engineering posture: from solving recurring symptoms to designing repeatable systems that improved delivery, reliability, and team capability together.

The Benchmarking Network describes itself as the world's largest healthcare benchmarking service, supporting more than 14,000 healthcare leaders in over 600 organisations. Its products collect, analyse, and distribute performance data used by NHS organisations and other healthcare providers. This made reliability, data integrity, and controlled delivery business requirements rather than purely technical preferences.

I was hired as a Back-end Software Developer in July 2024. The later scope recorded by RCI Group included backend engineering, DevOps engineering, and solutions architecture. My work sat at the intersection of four pressures:

1. A new product had to be delivered. The team was developing a replacement for legacy systems while continuing to support active users and internal project teams.
2. The architecture carried accumulated constraints. Presentations identified large SQL queries, stored procedures, cascaded REST calls, tightly coupled application and data concerns, and analytical workloads running against an operational database design.
3. The delivery system was too manual. Early materials called out the absence of CI/CD, inconsistent coding practices, weak release conventions, and slow or ambiguous review processes.
4. The team system was brittle. Important knowledge was concentrated, requirements could change under time pressure, review and decision paths were unclear, and recurring internal requests consumed significant engineering capacity.

I framed these not as separate complaints but as one socio-technical problem. Product decisions affected communication; communication affected code quality; code and delivery practices affected trust, speed, and the organisation's ability to respond to users. The leadership task was therefore to improve the system rather than optimise one team metric in isolation.

My working thesis was simple: technical leadership is the design of conditions in which good engineering decisions can be made repeatedly.

That meant combining four kinds of work:

• Architecture: create clear boundaries, choose technology for the workload, and reduce accidental complexity.
• Delivery: automate validation and deployment so feedback is fast, releases are repeatable, and rollback is credible.
• Risk management: protect data integrity and service availability during high-impact change.
• Capability building: make standards understandable, involve the team, sequence adoption, and measure the system instead of individual engineers.

I used presentations as decision tools throughout the period. They translated technical concerns into business consequences, exposed trade-offs, invited challenge, and created a shared record of the proposed direction. The sequence of the presentations also shows an evolution from component-level architecture to enterprise delivery and team resilience.

Starting with boundaries, not frameworks

My July 2024 architecture work focused on the structure of the new Benchmarker product. I contrasted database-centric, three-layer architecture with a domain-centred design and proposed a clean architecture that separated presentation, application, domain, and infrastructure concerns. At backend level, the design combined a FastAPI boundary, services and business rules, repositories, data models, and PostgreSQL behind explicit interfaces.

The purpose was not architectural fashion. The existing environment mixed concerns in ways that made change harder. The proposed design aimed to make the system usable, testable, maintainable, and easier to evolve without forcing unrelated teams or components to change together.

The accompanying PR review materials documented implementation-level choices that supported those goals:

• a repository pattern to separate data access from business logic;
• SQLModel for validation and schema integration with FastAPI;
• PostgreSQL with asyncpg and connection pooling;
• environment-based configuration to prevent unsafe assumptions about shared environments;
• Poetry for deterministic dependency management;
• unit, integration, and asynchronous test suites;
• clearer source, route, and migration layout;
• improved README, .gitignore, and example environment configuration.

This was leadership through coherence: individual code choices were tied back to a consistent operating model for the product.

Evaluating GraphQL with benefits, costs, and an adoption path

In August 2024, I presented a detailed case for GraphQL in response to repeated REST calls, under-fetching, over-fetching, frontend dependency on backend endpoint shapes, and maintainability pressure from multiple client experiences. The materials used a real Members API flow to show how multiple dependent requests could be represented as a single client-declared query.

Crucially, the recommendation was not presented as a universal rule. I documented the learning curve, schema-management burden, caching differences, security considerations, potential for expensive queries, and the risk of reproducing REST thinking inside GraphQL. I proposed small-scale integration first, followed by a time-boxed team induction, wider testing, and staged frontend adoption only where the evidence justified it.

That approach demonstrated a recurring leadership principle: technology selection should include the operating model required to use the technology well. A choice is incomplete without a migration path, learning plan, risk controls, and a definition of success.

Separating transactional and analytical workloads

By November 2024, I had extended the architecture discussion to the data layer. I identified a workload mismatch: transactional PostgreSQL structures were being asked to support long-running analytical queries, large aggregations, reporting, and stored-procedure-heavy logic. This increased performance, maintenance, and scaling risk.

I proposed an OLTP and OLAP separation using an extract-transform-load flow into an analytical store. The design covered scheduling, transformations, dimensions, measures, pre-aggregation, and downstream reporting. It also mapped the expected impact on backend, frontend, and project teams.

The sequencing mattered. I recommended delivering the new Benchmarker product first, then carrying out feasibility and tool selection, initial integration, migration of large queries, and fuller adoption. This avoided turning a sound long-term architecture idea into an immediate distraction from the primary delivery commitment.

Translating architecture into business value

The architecture presentations consistently connected technical choices to organisational outcomes:

• fewer cascaded failures and less coupling;
• faster, more flexible access to data;
• reduced maintenance overhead;
• better foundations for analytics-heavy workloads;
• improved ability to support multiple frontends and internal tools;
• a platform that was more robust, scalable, and adaptable.

The RCI Group wrote a recommendation later recording that I led the architectural design and development of a new generation of FastAPI-based, Azure-hosted applications and established cloud-native infrastructure standards. This provides independent confirmation that the work progressed beyond presentation into delivery.

Diagnosing delivery as a system

In January 2025, I presented engineering speed and delivery as related but distinct concepts. Speed described how quickly a unit of work moved; delivery described how much valuable, production-ready work reached users. Optimising one without the other could create local activity without useful outcomes.

I proposed measuring lead time, cycle time, pull-request review time, deployment frequency, change failure rate, and time to restore. I also separated the sources of friction into three connected domains:

• project and product dynamics;
• team and communication dynamics;
• code and development practices.

This prevented the common mistake of treating every delivery issue as an individual productivity problem. The unit of improvement was the engineering system.

Introducing CI/CD and version-control standards

I designed and implemented a CI/CD system that automated builds, validation, and deployment. The accompanying process materials established a consistent path from local development to production:

• GitLab CI checks on merge requests;
• automated linting and tests;
• pre-commit hooks for formatting, static analysis, and secret scanning;
• Dockerised services and consistent environments;
• GitLab container registry;
• a one-command local startup path;
• branch conventions for features, fixes, releases, and hotfixes;
• semantic versioning and automated tagging;
• gated merging after required validation and review;
• explicit support for reproducible releases and confident rollback.

The presentation materials also set the next capability horizon: declarative infrastructure, improved Azure deployment, automated performance tests, observability, and ephemeral preview environments for each pull request.

Outcome: 75 percent faster releases

The RCI Group recommendation states that the resulting CI/CD pipeline cut release times by 75 percent. The impact was larger than a faster deployment command. Automated feedback reduced the delay between writing code and discovering defects, consistent environments reduced configuration drift, and release tags made production artefacts identifiable and reproducible.

This changed the team's relationship with release risk. Delivery became a repeatable organisational capability rather than a sequence of expert-dependent manual actions.

One of the highest-risk initiatives during the period was the migration of historical healthcare benchmarking data from a legacy Microsoft SQL Server environment to PostgreSQL.

The constraints were severe:

• millions of healthcare records and complex relationships;
• zero tolerance for lost or corrupted records;
• active users who required continued availability;
• business rules accumulated over years;
• migration across all UK datasets in scope.

I architected a cloud-native data migration pipeline using Python and dltHub. The design treated resilience, validation, and continuity as first-class concerns rather than checks added at the end.

The migration achieved:

• 100 percent data integrity: no records lost and no data corruption;
• zero downtime: service availability was maintained throughout the migration;
• a reusable pipeline approach: extraction, transformation, validation, and loading were structured rather than handled as a one-off manual move.

This work is the clearest example of technical leadership under operational pressure. It required hands-on engineering, architecture, sequencing, verification, and an understanding that failures would have consequences beyond the development team.

Making hidden dependencies visible

By February 2025, I was describing brittleness across three levels: product and project dynamics, team and communication dynamics, and code and development practices. The failure modes included unclear requirements, reliance on key individuals, siloed knowledge, decision bottlenecks, poor communication, inconsistent standards, missing automation, and weak internal tooling.

I warned against random acts of change: isolated interventions without a clear strategy, owner, sequence, or measure. Instead, I proposed a staged roadmap:

• Short term: improve pull-request flow, introduce Git flow and pre-commit checks, agree coding and review practices, and run requirements-clarity workshops.
• Medium term: standardise development processes, build CI/CD, improve internal tooling, and establish team-wide knowledge sharing.
• Long term: measure developer experience and delivery, review outcomes, and continuously adjust the system.

Designing adoption, not just standards

The change plan paired cultural expectations with process support. It included review service levels, clearer ownership, rotating review responsibility, visible discussion of merged work, team feedback, and a schedule for introducing one practice at a time.

This mattered because standards imposed without context often become compliance exercises. I used workshops, technical presentations, PR reviews, and mentoring to explain why the changes existed and how they connected to delivery and business outcomes.

The RCI Group recommendation records the team effect: junior engineers gained clear patterns, senior engineers gained shared collaboration standards, and the team benefited from faster lint and test feedback on merge requests. It also states that I mentored engineers, established standards, and elevated team capability.

Treating internal users as customers

The presentations identified project and analytics teams as the platform's first and most frequent internal customers. Repetitive scripts, change requests, and support needs consumed substantial engineering time. I argued for better internal tools built closer to the backend, with a narrower stack that supported faster iteration and clearer operational control.

Even where these ideas remained roadmap proposals, they show a leadership move from feature delivery toward leverage: reducing recurring work so the team can spend more capacity on durable product value.

Quantified outcomes

• 75 percent reduction in release time after implementation of the CI/CD pipeline.
• 100 percent data integrity during migration of millions of healthcare records.
• Zero downtime throughout the migration.
• Automated validation on every pull request, including immediate lint and test feedback in GitLab.

Capability outcomes

• A new generation of FastAPI-based, Azure-hosted applications and cloud-native deployment standards.
• Dockerised services with consistent development, staging, and production runtimes.
• Shared practices for code review, pre-commit validation, branching, versioning, tagging, and release management.
• A clearer application architecture with separation between business logic, data access, and infrastructure.
• A team roadmap for DORA-style delivery measures, observability, performance testing, preview environments, and analytical architecture.
• Increased team capability through mentoring, technical induction, presentations, and explicit standards.

1. I connect architecture to the system of work

I do not treat architecture as a diagram that ends at code boundaries. I connect it to deployment, testing, team ownership, internal customers, operational risk, and future change.

2. I translate technical decisions for mixed audiences

The presentation record moves between system diagrams, API and database trade-offs, delivery metrics, team practices, risk, timelines, and business outcomes. This made complex decisions discussable by engineers, delivery leaders, and senior stakeholders.

3. I distinguish proposals from proof

I use phased experiments where evidence is incomplete and make stronger commitments where results are validated. The GraphQL and OLAP materials include caveats, sequencing, and learning plans rather than technology advocacy without constraints.

4. I lead through enablement

The standards were designed and socialised as tools that made good work easier. Mentoring, shared review practices, workshops, and visible rationale helped the team adopt them.

5. I operate effectively at multiple altitudes

The same body of work spans source layout, test suites, database drivers, pipeline automation, data migration, cloud infrastructure, target architecture, performance strategy, developer experience, and organisational change.

6. I manage risk in mission-critical change

The migration outcome shows disciplined execution under zero-loss and zero-downtime constraints. The delivery work shows a preference for repeatability, validation, reproducibility, and rollback.

1. The bottleneck is often a relationship between systems. Product ambiguity, team communication, and code quality reinforce one another. Improving one in isolation has limited effect.
2. Architecture needs an adoption plan. Training, experiments, sequencing, ownership, and feedback are part of the technical design.
3. Automated feedback compounds. Pre-commit checks, CI validation, containerised environments, and reproducible releases save small amounts of time repeatedly while reducing risk.
4. Metrics should improve the system, not judge individuals. Lead time, deployment frequency, change failure rate, time to restore, and review time are most useful when they expose process constraints.
5. Credibility comes from separating aspiration from evidence. A roadmap can be ambitious, but completed outcomes should be claimed only where the evidence supports them.
6. Technical leadership is a leverage role. The aim is not to become the key person every decision depends on. It is to build architecture, automation, standards, and shared understanding that allow the team to succeed without fragile dependencies.

I joined The Benchmarking Network in July 2024 as a Back-end Software Developer, but the main problem quickly proved broader than backend implementation. The new Benchmarker product was being built alongside legacy constraints, manual delivery, inconsistent engineering practices, and high-risk healthcare data migration work.

I treated the challenge as one connected system. I helped define a clean, FastAPI-based architecture on Azure; introduced repository, testing, configuration, and data-access patterns; designed and implemented CI/CD, containerisation, pre-commit checks, release conventions, and automated validation; and created a phased roadmap for API, analytics, developer-experience, and team improvements. I also architected a Python and dltHub migration pipeline for millions of records.

The result was a 75 percent reduction in release time, 100 percent data integrity and zero downtime during migration, and a more repeatable engineering operating model. The leadership lesson was that the strongest technical outcomes came from combining architecture, delivery automation, risk management, and team enablement rather than treating them as separate initiatives.