Engineering leadership · Software architecture · Distributed systems
Engineering leader. Hands-on software architect.
I lead engineering teams and the systems they build — setting technical direction, growing engineers, and seeing work through to production. And I stay close enough to the architecture and the code to make hard calls from first-hand knowledge.
01Selected work
Three stories about building across system boundaries, leading a team through change, and changing a critical system safely, followed by deep dives on the judgment behind the work. Details that belong to employers — names, partners, systems, numbers — are left out.
01
The web architecture for a regulated onboarding experience launched from an external enterprise platform: a server-driven workflow, identity integration, asynchronous account setup, and observability by design — delivered while owning the frontend workstream across several repositories.
02
Stepping into a team mid-transition: making ownership explicit, protecting engineering focus, and helping the team deliver consistently — without adding process for its own sake.
03
Moving a tightly coupled integration path onto a durable event architecture — preserving delivery, tolerating downtime, supporting replay, and giving every consumer a safe path from old to new.
Two teams, one customer-facing experience: clear boundaries, integrated validation, controlled activation — and an owner for it after launch.
External users were getting HTTP 503s while the application looked healthy. The cause was a network rule that no longer matched where the workload lived.
The operating model I lead with: delegate decisions along with the work, protect engineering focus, stay technically close without taking over, and make it clear what needs the lead — and what doesn’t.
How AI fits into disciplined engineering: design intent made explicit in specifications, the tool used to challenge and accelerate the work, and verification and accountability kept with the engineer.
02Leadership
17 years in, the work has moved from writing features to setting technical direction, growing engineers, and leading delivery across teams — without stepping away from the architecture.
Since 2004
BSc Computer Science, Software Engineering, at the University of Information Sciences.
Since 2009
Web applications, third-party integrations, and CMS platforms for independent clients.
Since 2016
Architecture ownership and technical direction on full-stack and real-time products, with mentoring across distributed international teams.
Since 2021
Broader production and platform responsibility: systems owned end to end, delivery, and technical hiring.
Since 2022
Formal team leadership: cross-team delivery, organizational change, and engineering standards.
Since 2024Now
Broader engineering leadership, while staying hands-on in the architecture and the code.
A lead’s job is to make the team faster and more autonomous: remove blockers, protect focus, and make synchronous time earn its place. Status can travel async; decisions, design, and hard problems get the room.
I stay close enough to the code to review it, debug it, and write it. Technical decisions hold up better when the person making them can trace the request themselves.
Engineers grow into leads by owning outcomes, not by collecting tickets. I delegate real decisions and coach through them rather than making them for people.
The same incident needs a precise root cause for engineers and a clear statement of impact and risk for leadership. I write both, and keep them consistent.
03Approach
They follow the loop in Fig. 1 — and they’re as much about the organization around a system as the code inside it.
01Build
Architecture is mostly a handful of decisions that are expensive to change later. I make those deliberately, write down why, and keep everything else as simple as the problem allows.
02Ship
Deploying code and releasing behavior are separate events. Feature flags, production-like validation, and a written go-live plan turn a launch into routine work instead of an act of courage.
03Run
Design for the failures you will actually get: dependencies that time out, consumers that fall behind, networks that change underneath you. Retries with limits, dead-letter paths, idempotency, and replay are design decisions, not patches.
04Operate
A system isn’t finished until people other than its authors can run it: alerts that reach whoever is on call, runbooks, clear ownership, and postmortems that change something.
04Expertise
Grouped by the kind of problem each area solves, with the stack underneath.
01
Setting technical direction and helping teams deliver on it — while growing the people doing the work.
02
Service boundaries, event-driven design, and integrations that keep working when parts of the system don’t.
03
What happens after deploy: signals, incidents, and making sure each one changes something.
04
Infrastructure as code, containers, and releases that can roll forward — and back — safely.
05
Web applications with a clear model of state, data fetching, and rendering.
06
APIs and services on Node.js, with data stores chosen to fit the problem.
Across every area
I use AI every day as part of how I build — writing specs, investigating unfamiliar code and failures, implementing, and reviewing. It makes the work faster; the architecture, verification, trade-offs, and accountability for what reaches production stay with the engineer.
05Contact
If you’re building something technically ambitious, working through a hard systems problem, or looking for experienced engineering leadership, I’d be glad to hear from you. Messages here come straight to me.