Not a portfolio of perfect projects. A few pieces of work I still think about because they changed something real: a system, a team, a relationship, or the way an organisation understood its data.
I inherited a production AWS platform that was expensive, hard to maintain, and built without enough understanding of how the business actually used it. The tempting version of the job was to replace the infrastructure and call that progress.
The better work started earlier: process analysis workshops, clearer data modelling around real operational workflows, and enough business context to avoid turning old confusion into cleaner-looking architecture. The platform rebuild mattered, but so did the standards, documentation, CI/CD, testing and data literacy work around it.
I'm proud of this because it connected technical delivery to organisational understanding. The result was not just a cheaper platform, but a data function the business could start to trust and use more confidently.
I joined to take over a contractor-built platform the organisation could not maintain or extend with confidence. Fixing the system mattered, but the bigger risk was leaving them dependent on another external handover.
I designed the AWS ingestion framework and Snowflake warehouse, then hired and onboarded engineers around it. The goal was not just a better platform. It was an internal team with enough context, standards and confidence to keep improving it after the initial rescue.
That is the part I'm proud of: shifting ownership from a fragile arrangement to a team that could understand, operate and change the platform themselves.
Related idea: future you is a stakeholder →One of the pieces of work I think about most was not a platform migration. It was helping a technically strong engineer move from needing answers checked to trusting their own judgement.
The technical gap was smaller than it first looked. The real blocker was confidence: understanding why modelling mattered, then learning to act on good judgement without waiting for someone else to validate it. That meant asking better questions, giving space for decisions, and making sure the wins were noticed.
I'm proud of this because it is the kind of leadership that compounds quietly. A stronger engineer does not just deliver more work; they raise the level of the team around them.
Related idea: developing engineers who don't need managing →I joined an established AWS and DBT environment where the architecture had grown organically for long enough that nobody had a clean view of the whole thing. Costs were high, failures were increasing, and the team had limited visibility into why.
I reviewed the architecture piece by piece, surfaced expensive bottlenecks, and re-orchestrated the codebase for more parallelism and automation. The technical work reduced cost and failure risk; the mentoring alongside it helped the team understand the new shape rather than simply inherit another black box.
I'm proud of the balance: practical savings, better reliability, and enough explanation that the work became part of the team's capability rather than just my intervention.
Building a greenfield multi-tenant BI platform to consolidate hundreds of client databases sounds like a technical problem. The harder challenge was organisational: designing something that could serve hundreds of slightly different clients without creating a maintenance burden that grew with every new one.
The decisions that mattered most weren't about which warehouse or which BI tool. They were about where to standardise and where to allow variation, how to give clients self-service access without letting the estate become impossible to reason about, and how to make the operational model sustainable for the team running it.
I'm proud of this because it was where I learned that scale is mostly a design problem, and that the right time to think about it is before you need to.