Cloud Architect
End-to-end ownership of the stack, the cloud infrastructure, the security model and multi-tenancy. On AWS since 2019 — CDK, DynamoDB, EventBridge, Step Functions, ECS — with security designed in rather than added later.
Services
One engagement, not a menu. I take on the engineering-management mandate — the system your engineers work in — and hold the cloud architecture, the hardest code and the coaching inside it at the same time. None of that scales by working harder, so each role gets turned into a system that keeps running when I'm not in the room.
Engineering management, as the single point of accountability for people, process and team health. In practice: hiring and onboarding, 1:1s, a training system with a budget attached, code review with an SLA, ceremonies that produce decisions instead of updates, metrics that describe the system instead of ranking people, and decisions written down where the next person can find them.
It works as a fractional role because the output isn't my own throughput. I don't produce sprint points and I don't absorb the urgent incidents. What stays behind is systems, processes, more capable people and better decisions — the parts that keep working on the days I'm not there, which is why the value compounds.
What the role owns, what it doesn't, and who decidesFour more roles run inside the mandate at the same time — not as extra engagements, and not as a menu to pick from.
End-to-end ownership of the stack, the cloud infrastructure, the security model and multi-tenancy. On AWS since 2019 — CDK, DynamoDB, EventBridge, Step Functions, ECS — with security designed in rather than added later.
Production code on the parts of the system nobody else has the context to carry: auth layers, deploy infrastructure, migrations that cross codebases. Architecture gets written, not supervised.
Biweekly 1:1s run as coaching rather than status reports, growth plans people can actually see, and feedback delivered while it can still change something.
A validation gate between enthusiasm and adoption: independent study, a proof of concept on a real use case, a Tech Radar placement backed by a decision record, then training for the team. The radar format is ThoughtWorks', the decision records Nygard's.
The templates are the easy part. What transfers is knowing which system to build first in a company that has none of them.
The order matters more than any single system: process before ceremony, ceremony before metrics, metrics before targets. Installing them in any other order is how transformation programmes fail.
The fastest way to find out whether this fits is a 30-minute call about your team — where the systems are missing and what's getting in the way. No pitch.
Book a free intro call