One engineer, a long time in the trade

I’ve spent most of my working life as the person who gets called when something important stops working and nobody’s quite sure why.

That job teaches you things a specialization doesn’t. You learn that the database was fine and the problem was DNS. That the security incident started with a permission someone granted eighteen months ago, for a perfectly good reason. That the application everyone wants to rewrite isn’t actually the bottleneck. Systems tend to fail at their edges, and the edges are exactly where narrow expertise runs out.

How I got broad

I started in 2000 as a web designer and developer, which is where the name comes from — W3Fix has been mine, on and off, since 2008. For a stretch it was the whole job: small-business networks, server hardening, firewall policy, websites and the databases behind them. You learn a lot running the entire stack for someone when there is nobody else to escalate to.

Then I went deep instead of wide for a while. Four years running IT for a municipal government — fourteen locations, four hundred–odd systems, sixteen production SQL servers — where I wrote the interface between a custom Windows remittance application and an IBM 3270 mainframe. That component has since processed billions of dollars in tax transactions. I have never been more careful with anything in my life.

After that, e-commerce infrastructure at scale and a team of eight engineers, then identity and access automation for a large healthcare payer, where I architected the first deployment of SailPoint IdentityIQ into an EKS cluster that the vendor had. These days my full-time work is principal-level security engineering for a global healthcare enterprise: event-driven automation platforms, IAM, and secret scanning across six thousand or so repositories.

W3Fix runs alongside that. It’s deliberately a practice rather than an agency — when you hire it, you get me, not a sales call followed by someone more junior. It also means I take on a small number of engagements at a time. That’s a real constraint, and I’d rather say so plainly than discover it with you halfway through a project. The upside is that I can afford to be selective, and to tell a client that the thing they asked for isn’t the thing they need.

What I’m actually good at

Diagnosis, mostly. Being handed a system nobody fully understands anymore and working out what it does, what’s load-bearing, and what can safely change. A lot of engagements that start as “can you build X” turn out to be “can you work out why X keeps happening” — and honestly, that’s the part I enjoy most.

After that, translation. Explaining a technical tradeoff to someone who has to make a business decision about it, without either dumbing it down or hiding behind vocabulary. A surprising amount of engineering value gets lost in that gap.

And automation, in the unglamorous sense. Replacing the weekly spreadsheet somebody dreads with something that refreshes on its own. Turning a patching window that used to cost hours of downtime into minutes. Most of the value I’ve delivered over the years looks like that rather than like a rewrite.

What I’m not

I don’t take visual design work. I spent years doing it, and I can still build the front end of a thing perfectly well — but the part where we go around four times on a layout and land back at the first one isn’t work I want anymore, and there are better tools and better people for it now than there were when I started.

I’m also not the right choice if you need a large team ramping up quickly, or round-the-clock staffed on-call — my availability is real but finite. And I’m not much use on engagements where the goal is to make the client permanently dependent on the consultant; that’s a real business model, it’s just not this one.