After fifteen years in commercial software I still describe myself the same way: an engineer who can draw the architecture, an engineering manager who can run the room, and a solution architect who can tie both to business reality. The through-line is not a title - it is how I move from ambiguous problem to shippable system without losing the thread.
Top to bottom, without losing the plot
I am comfortable from schema design and API contracts through production logs, deploy paths, and the conversation in a board meeting. That full-stack depth is deliberate: you cannot pinpoint a failure or defend an architecture if you have not recently touched the layer where it hurts. When pressure rises, my default is diagnosis first - narrow the blast radius, name the owning component, prove the fix against runtime evidence - then scale the answer into something the team can repeat.
Strong context switching is part of the job, not a boast about workload. Different clients, stacks, and time zones ask for different mental models; the skill is keeping each boundary clean so work in one lane does not contaminate another. I treat that as architecture for attention: explicit ownership, durable notes, and handoffs that the next session can read cold.
Leadership that stays technical
I have led engineering groups of roughly fifteen people and delivered on global programmes from discovery through production. At that scale the work is part direction, part operating rhythm: who owns which surface, how incidents become standards, how executives hear truth without drowning in jargon. I mentor by building the map and scaffold, then handing off ownership where someone's domain knowledge is stronger than mine - always with verification and risk visible, not buried in optimism.
Stakeholder and shareholder reporting, recruitment design, and cross-team coordination sit in the same picture as code review and architecture review. The goal is not to manage away from engineering but to make engineering legible enough that decisions stick after the meeting ends.
Applied AI with guardrails
AI belongs in the delivery loop only where it respects the system around it. My workflow is intentionally boring: capture facts locally, preprocess deterministically, route reasoning to a task-fit model, verify against human and runtime evidence, then compound what worked into reusable standards. Lightweight models handle faithful extraction; heavier synthesis stays a separate, deliberate step. Prompts and outputs stay bounded; private material stays behind explicit boundaries; nothing important lives only in chat history.
That discipline is what lets AI increase speed without trading away judgment - the same bar I apply when advising teams on adoption: evidence, rollback, accountability, not magic.
Orchestrated agents, not one endless chat
The same org shape shows up in how I use coding agents. Mixed intent is where copilots fail - infrastructure, production change, and unrelated edits in one thread blur context and permissions. I run a small roster instead: an orchestrator that routes intent, and domain specialists that own a repo, stack, or client boundary. The orchestrator names the owner and stops; it does not implement another domain's code because the window is open.
Intent
|
v
Orchestrator (route only)
|
+-- Specialist -- Specialist -- ...
|
v
Ship + update durable skills / rules on disk
Memory lives in markdown skills and rules - deploy state, traps, test commands, copy preferences - not in an ever-longer transcript. When something repeats, I fix the playbook (FYS: name the mistake, patch the file the next agent reads, move on). Workflow skills sit underneath: plan before a wide change, land increments, verify in a real browser, review before merge. Work that spans repos lands on a priority board first; execution still happens in the workspace that owns the code.
I dogfood this daily and use the same story in consultancy work: orchestrated agents, human gates, and self-learning documentation that survives when people change. The runnable stack behind it is described on My Open Claw in the private section of this site.
How I prefer to work
Controlled, reversible automation over heroics. Iterative delivery - narrow version, inspect real output, refine from concrete failure. Documentation as an engineering platform: placeholders over invented content, public and internal material separated on purpose. Diagnose before changing; report operational state plainly; leave systems stronger after recovery than before the incident.