Work

Six problems I get called for. Every one of them is something I have done, not something I could do.

For a national healthcare payer, the platform layer of a Databricks environment on AWS: HIPAA and HITRUST compliant, governed through Unity Catalog, private networking, single sign-on. Every environment from development to production provisioned as code and promoted through one pipeline, with policy and security scanning catching misconfigurations before infrastructure exists rather than in a later review. Each new capability cleared a standing security review before anyone could use it.

For a credit bureau, 700 corporate tenants moved to AWS in four waves over six months. One database per tenant, which is what made waves possible at all: pooled storage moves everyone or no one. Cutover and rollback planned per wave against a Friday-evening-to-Monday-morning window. The tenancy decision determined the migration strategy, not the other way round.

Controls designed as configuration rather than written policy, with infrastructure code and pipeline gates enforcing them, so a deployment produces its own audit evidence and the controls stay provable between audits. Behind that: five years leading SOC 2 audits at a global public cloud provider, and designing platforms to emit the evidence rather than assembling it by hand at audit time.

Global key management and object storage at a public cloud provider, where an outage stops other companies trading. Upgrades, migrations and capacity expansion designed to happen without interrupting the service. New regions built out on three continents, including solving the ordering problem a key management platform creates for a new region, where everything needs encryption before the encryption hardware has arrived. Disaster-recovery runbooks and the annual rehearsals that prove them. And incident command when it goes wrong anyway, including a thirteen-hour bridge call when half a hardware security module fleet stopped responding.

One engineer into a practice of more than 70, staffed across 13 product teams, sustained over eight years. What made it hold was not headcount: a standing daily session with the executive sponsor, quarterly reviews that led with the bad news alongside the good, and staying embedded in the delivery work rather than above it, which is the only way to hear the friction between teams that reporting lines keep separated.

Capable models still lose sight of a whole system and rebuild what already exists. I run coding agents under a private framework of defined roles, automated gates and independent verification, built specifically for that failure, and have delivered two products through it, including a multi-tenant industrial traceability platform as its sole developer. The discipline is the point, not the tooling. The writing goes into how it works.

Independent, working through 494 Group, corp-to-corp or through a consulting partner. Typically one of four shapes: architecture and platform build; migration leadership; compliance and audit readiness; or embedded as the technical counterpart to the executive sponsoring a large program, which is a posture rather than a title and is the one people ask about least and need most.

Most engagements are one person, and that is often the right answer rather than a compromise: a platform decision made by one architect who stays through the audit beats the same decision made by a group that has moved on by then. When a program is genuinely bigger than that, I bring in people I have worked with rather than hand you names I have not.

I have built the large version of this. One engagement went from a team of one to a practice of more than 70 engineers across 13 product teams over eight years, and the hiring, onboarding and growing people into senior and architect roles was the work rather than a side effect of it. So the question of how many people a program needs has an honest answer in both directions, and it is worth asking before anyone quotes you a team.

Get in touch if one of these is the problem in front of you.