Principal Engineer

I have helped take a company from twenty people in one room to a public company of over a thousand — and built the systems that made it possible

What I do

I have been a principal engineer for several years. In practice that means I design and build the systems a business cannot operate without — the data platforms, the back-office automation, the services other teams build on top of — and I am accountable for them long after they ship. The work I am proudest of is invisible: it is the thing that stopped being a problem.

I have done that across several companies and several industries, at every stage from the first line of code to the scale where an outage is somebody's bad week. The range is the point. The decisions that matter at twenty people are not the ones that matter at a thousand, and knowing which of the two you are making is most of the job.

I lead as well as build. I have coordinated teams across functions and time zones, managed engineers directly, and spent a lot of time on the unglamorous half of seniority — making a plan legible, making a review worth someone's afternoon, making sure whoever picks this up in a year has what they need.

What that has looked like

• Growing with a company from under twenty employees to a public one of over a thousand, and keeping the systems ahead of the growth rather than behind it
• Delivering projects end to end — scoping them, building them, shipping them, and still owning them a year later
• Coordinating teams across functions and time zones, and managing engineers directly
• Arriving in an unfamiliar industry and being useful in it quickly, which I have now done more than once

The thread that keeps reappearing

Healthcare is the problem space I keep coming back to: a final-year project detecting brain aneurysms from medical imaging, a semantic reasoner for drug incompatibilities at Hospital Gregorio Marañón, and health again today. Engineering holds my attention longest when the outcome is somebody being better off.

How I work, and with what

Tools are the least interesting part of the job, so here they are grouped by the kind of problem they get used on rather than by how much I like them.

The list moves. What does not is the habit of picking the boring option unless there is a reason not to, and writing down the reason when there is.

If you are building something where this would help, I would like to hear about it. Get in touch