I build systems that turn friction into flow.
This page is the closest thing I have to a conventional CV.
It is part professional synopsis, part portfolio, and part operating manual: the work I have done, the systems I like building, the way I tend to think, and the things that keep me curious.
I work across cloud operations, escalation engineering, automation, agentic AI, workflow design and technical learning. My strongest work tends to happen in the awkward space between established systems, where the official answer is often “this is just how it works” and my instinct is usually:
Does it have to?
At a glance
I am a multidisciplinary escalation engineer and systems thinker with more than 19 years of experience spanning broadband networking, application delivery, cloud operations, customer incident management, internal tooling and automation.
My career has moved steadily outward in scope:
network troubleshooting → application delivery and load balancing → escalation engineering → cloud operations → workflow architecture → automation → agentic AI
The technology has changed. The underlying instinct has not.
I tend to be strongest when a problem is technically messy, distributed across multiple systems, expensive in human attention, difficult to explain cleanly, full of repeated manual work, or sitting somewhere between “technical” and “organisational”.
My recurring pattern is:
observe the friction → model the system → find leverage → automate what should not require heroics
Career
Amazon Web Services (AWS)
Escalation Engineering · 2016–present
Senior Escalation Engineer
2021–present
Escalation Engineer II
2018–present / overlapping progression in LinkedIn history
Escalation Engineer
2016–2018
AWS has been the largest chapter of my career so far.
My work sits at the intersection of cloud operations, customer-impacting events, technical escalation, internal tooling and operational improvement.
Over that time I have worked across areas including large-scale operational escalation and incident response, AWS Health and Event Management, customer-impacting cloud events, technical and operational coordination, mentoring and peer enablement, internal automation, workflow design, technical simulations and training, GenAI experimentation, agentic tooling, scripting and browser automation.
I am a designated Subject Matter Expert for AWS Health and Event Management, and much of my work has involved translating technically complex events into something actionable for customers, engineers and operational teams.
Contributions I am proud of
Operational automation
I have repeatedly taken workflows that depended on people remembering, copying, clicking, checking and manually constructing artefacts, and turned them into systems.
That has included eliminating repeated manual steps, connecting internal systems that were never designed to work together, building lightweight integrations around existing platforms, automating documentation-heavy work, replacing fragile human memory with explicit state and tooling, and reducing the cognitive load of people already handling multiple concurrent workstreams.
The goal is not automation for its own sake.
The goal is usually:
return human attention to the parts of the job that actually require a human.
Internal automation-platform expertise
I have developed deep expertise in a broad internal automation platform used across my organisation.
Only a relatively small cohort use it at an advanced level, and I tend to approach it less as a collection of features and more as a composable capability layer.
I map what the platform can already do, what the workflow actually needs, where the two overlap, where the gaps are, and which gaps can be bridged with scripts, userscripts, polling, APIs or supporting services.
That is often where my favourite work begins.
Workflow architecture
I have spent substantial time designing operational workflows in Asana and related systems.
One implementation was recognised by Asana as an excellent example of using the platform in the way it was intended: not merely as a task list, but as an operating system for coordination, ownership, state and visibility.
I care deeply about that distinction.
A workflow tool should reduce uncertainty.
If people have to remember the process themselves, chase state manually, or act as middleware between systems, the workflow is not finished.
Generative AI and agentic systems
More recently, I have focused heavily on applied GenAI and agentic systems.
My interests include agent orchestration, persistent context, context engineering, tool-using AI, human-in-the-loop systems, AI-assisted implementation, long-running task workflows, and using models as callable expertise inside larger systems.
I am particularly interested in the boundary between what a human needs to know deeply and what can be safely externalised to an AI collaborator.
Technical learning and simulation
I enjoy building ways for people to learn systems by interacting with them.
That has included simulation-based training, branching decision experiences, hands-on technical facilitation, GenAI demonstrations, hackathon organisation and judging, documentation and knowledge systems, and mentoring.
I tend to treat explanation as another interface-design problem.
A concept can be technically correct and still be practically unusable if the interface to understanding it is poor.
Citrix
Networking, application delivery and escalation engineering · 2011–2016
Senior Escalation Engineer
2016
Escalation Engineer
2014–2016
Associate Escalation Engineer
2013–2014
Technical Support Engineer — Networking
2011–2013
Citrix was where my networking foundation became escalation engineering.
I worked deeply with technologies and problem spaces including NetScaler / application delivery, load balancing, TCP/IP, DNS, SSL, high availability, Access Gateway, packet analysis, Wireshark, network administration, virtualisation, and customer-facing technical escalation.
This period taught me a great deal about the difference between knowing a product and understanding a system.
Escalation work rarely arrives as a cleanly isolated failure.
It arrives as a chain of interacting assumptions.
That suited me.
Irish Broadband
Technical and premium support · 2007–2011
Premium Support Engineer
2009–2011
Technical Support Engineer
2007–2009
This was my professional foundation in networking and technical support.
It gave me practical exposure to networking, broadband infrastructure, customer troubleshooting, Cisco technologies, TCP/IP, DNS, escalation and fault isolation.
The experience established a pattern that remained throughout my career: I enjoyed the cases that crossed boundaries and refused to fit neatly into the first diagnosis.
Imagine Broadband
Technical Support Technician · 2008–2009
Another early networking role, overlapping with the beginning of my broader broadband-support career.
It contributed to the same foundation: customer-facing technical troubleshooting, network behaviour and the practical reality of keeping connectivity working outside a lab.
Technical lineage
One way of reading my career is as a widening set of abstraction layers.
Networking foundation
TCP/IP · DNS · switches · Cisco · wireless · packet analysis · Wireshark
Application delivery
load balancing · SSL · high availability · gateways · NetScaler · virtualisation
Cloud operations
AWS · escalation · event management · distributed systems · operational response
Automation
Python · JavaScript · browser automation · APIs · internal platforms · workflow tooling
Agentic systems
GenAI · tool use · orchestration · context engineering · long-running agents · AI-assisted implementation
I still find it useful that the upper layers sit on top of the lower ones.
An AI agent may be glamorous.
Eventually, however, something still has to resolve DNS.
Certifications and formal learning
My certification history reflects the technical path I have taken.
AWS
- AWS Certified Solutions Architect — Associate
Issued 2020, expired 2023 - AWS Certified SysOps Administrator — Associate
Issued 2018, expired 2020 - AWS Certified Generative AI Developer — Professional
Currently preparing; exam scheduled for October 2026
Citrix
- Citrix Certified Professional — Networking (CCP-N)
Issued 2014, expired 2017 - Citrix Certified Administrator for NetScaler 9
- Citrix Certified Administrator for Citrix Access Gateway 9 Enterprise Edition
- Citrix NetScaler 10 Essentials and Networking
Networking
- CompTIA Network+
I do not treat certifications as a substitute for practice, but they have been useful milestones as my work moved from networking into application delivery, cloud systems and now GenAI.
What I build outside work
Agent-assisted engineering
I run a long-term experiment in combining human judgement with persistent AI context, tools and executable workflows.
This includes specialised agents, long-running orchestration, reusable skills, local and remote automation, structured task handoff, and systems that can act rather than merely answer.
I am especially interested in what happens when AI stops being a chat window and becomes part of a working environment.
Domestic Automation Daemon
A private automation layer for the practical moving parts of home life.
It began from a simple premise:
repeated domestic coordination is still coordination
The implementation combines Python, Telegram, self-hosted services and task automation to reduce recurring friction.
The name is DAD, naturally.
Personal infrastructure
I run and maintain my own small self-hosted environment for experiments, services, automation and publishing.
That includes Linux, Python services, reverse proxies, webhooks, APIs, automation daemons, small web applications and agent tooling.
I enjoy this scale of infrastructure because the distance between idea and implementation is short enough to stay playful.
How I think
I reframe before I optimise
When a problem says:
“How do we make this process faster?”
my first instinct is often:
“Why does this process exist in this shape at all?”
One of my favourite early examples came from school.
A teacher posed a puzzle:
Anne is at position A and wants to reach B. Without physically or verbally influencing her, how can we prevent her from reaching B?
My answer was:
Create a C that Anne wants more.
The useful move was not blocking B.
It was changing the goal landscape.
That is still how I like to approach systems.
I learn by building an internal model
I am rarely satisfied with procedural knowledge alone.
I want to know what state exists, what changes it, what depends on what, where the interfaces are, what happens when something fails, what can be removed, what can be automated, and what remains genuinely human.
Once that model becomes coherent, my speed tends to increase dramatically.
I often find myself moving from:
using the system → playing the system
That transition matters to me.
I connect domains
I am interested in knowledge that travels.
A concept becomes much more valuable when it can escape the field where I learned it.
A hypothetical community water problem once immediately reminded me of a retry storm in distributed systems: capacity returns, everyone retries at once, recovery itself causes the next overload.
That changed the solution space from “bigger pipes” to ideas like demand shaping, staged recovery, backoff, throttling and capacity augmentation.
The town did not become a software system.
The structure simply transferred.
Capability orchestration
One of the clearest descriptions I have found for my current working style is:
I know the shape of the capability landscape.
I do not pretend to have every implementation detail memorised.
Instead, I often know what kinds of systems exist, what each is good at, what model it belongs to, what it can connect to, where the interfaces are, and which missing pieces can be filled by code, automation or AI.
Paired with an AI coding assistant, that becomes extremely powerful.
I can design a system, identify the right primitives, delegate unfamiliar implementation detail, and still retain enough architectural understanding to evaluate whether the result makes sense.
That is different from claiming mastery of every underlying technology.
It is a form of architectural synthesis.
And it has produced some wonderfully strange systems.
Music
I have played guitar for many years and have performed live.
I am not a formally trained musician.
I read notation poorly, make mistakes, and have never been especially interested in presenting myself as a technical virtuoso.
But I treasure the skill I have.
One of my strongest memories is playing a borrowed 26-fret Ibanez on stage, knowing the set well enough that I could stop thinking about merely surviving the songs and start improvising properly.
Bends. Tremolo. Tapping. Ridiculous guitar poses. The full ceremony.
That feeling has unexpectedly transferred into technical work.
At first I am deliberate:
understand the workflow
map the constraints
connect the systems
make it work
Then, once the system becomes fluent, I start riffing on it.
“Why does anyone still need to click this?”
“Why is that document still being produced by hand?”
“If these two capabilities exist, why are they not connected?”
“Can we remove this whole step?”
Music does not leak into my work as theory.
It leaks in as improvisational confidence.
Once I understand the instrument, I want to play it.
Formative influences
I have always been drawn to systems that reveal themselves through use.
Games were one early environment for that. They taught me persistence, iteration, interface fluency and the satisfaction of discovering hidden rules. They also nudged me toward computers, typing and networking.
The important part for me is not the amount of time spent playing them.
It is the habit they helped establish:
complex systems become less mysterious when you interact with them long enough to discover their rules.
Another major influence was Star Trek: The Next Generation.
What stayed with me was not the technology itself, but the model of competence: technical fluency, calm decision-making, specialist expertise, ethical seriousness, disciplined communication, hierarchy without intellectual passivity, and confidence that the visible console was only part of a larger hidden system.
It gave me an early image of what capable adulthood could look like.
Curiosity as a practice
I regularly wander into areas that are not immediately useful.
That is deliberate.
Some become projects.
Some become metaphors.
Some become tools years later.
I have learned not to demand immediate ROI from curiosity.
The connections often arrive later.
A small experiment in self-benchmarking
Recently I started testing some of my own cognitive strengths and weaknesses.
Not because I wanted an IQ badge.
Quite the opposite.
I wanted to understand the shape of my cognition.
A few interesting results:
| Probe | Result | What interested me |
|---|---|---|
| Digit span | 6 forward / 5 backward | Ordinary storage, much harder manipulation |
| Corsi spatial span | 6 | Spatial and verbal short-term capacity were remarkably similar |
| Mental rotation | 87% | Strong result despite a poor result on a different 3D format |
| Matrix reasoning | 28/36 | Around average; interface and representation mattered enormously |
| Digit-symbol substitution | 56 vs reference median ~48 | Rapid within-task acceleration with high later accuracy |
| Operation span | 89% letter recall / 93% maths | Working memory remained robust under interference |
| Mixed task switching | 40/40 accuracy | Accurate, but rule changes imposed a measurable reconfiguration cost |
The most useful discovery was not a score.
It was this:
Performance = cognition × representation × interface × current state
A benchmark measures the person.
It also measures the fit between the person and the benchmark.
Conditions where I do my best work
I tend to thrive when the problem is real, the boundaries are imperfect, I am allowed to question the framing, I can build a coherent model before being interrupted repeatedly, I can cross system boundaries, repeated friction can be automated, there is room to experiment, and the goal matters more than the ceremony.
I struggle more with unnecessary context fragmentation, workflows that depend on human memory, process maintained purely because it already exists, systems that hide their state, and repeated manual effort treated as normal.
Once I understand a system, I usually want to improve it.
Breadth, depth and integration
I have become interested in the idea of polymathy, but I use the word cautiously.
The definition that interests me is not:
master of many things
It is:
breadth + depth + integration
Breadth expands the conceptual territory.
Depth tells you which bridges are real.
Integration allows useful ideas to move between regions.
A lateral thinker can only move as far laterally as the conceptual world they can see.
Or, less formally:
A crab in a four-foot box can only lateral for four feet.
So I keep expanding the box.
Areas of depth and active practice
Cloud systems and operations
Distributed systems, operations, incident reasoning, automation and reliability.
Networking and application delivery
TCP/IP, DNS, load balancing, SSL, packet analysis, high availability and escalation.
Automation and Python
Scripting, API integration, tooling and removing repeated human effort.
Agentic AI
Tool-using models, orchestration, persistent context and AI-assisted engineering.
Workflow architecture
State, ownership, dependencies, visibility, coordination and automation.
Technical communication
Documentation, facilitation, simulation and making difficult systems tangible.
Systems thinking
Feedback loops, bottlenecks, constraints, hidden assumptions and reframing.
Capability orchestration
Knowing what can be connected, what should be delegated, and how different technical capabilities can compose.
Music
A long-lived creative practice and a surprisingly important source of how I approach technical improvisation.
Selected principles
Useful over impressive.
The best technology often disappears into a better day.
Systems over heroics.
Repeated effort is usually an unclaimed design problem.
Understand before automating.
Automating a bad process just makes the bad process faster.
Interfaces matter.
A capability that cannot be understood or reached is effectively absent.
Curiosity compounds.
Knowledge does not need to justify itself immediately to become useful later.
Leave room to play.
Mastery is not always the point. Fluency is often enough to make something new.
What I am looking for
I like strange, useful problems.
The best ones tend to sit between established categories:
- software and people
- automation and judgement
- AI and real work
- systems and behaviour
- technical capability and human friction
If the obvious answer is “more process”, I will probably want to inspect the problem more closely.
And if, somewhere in the conversation, somebody says:
“I didn't realise you could connect those two things.”
that is usually a very good sign.
Find me elsewhere
This page is intentionally broader than a traditional CV. It combines professional experience, selected projects, working style and personal influences. The benchmark section reflects informal self-testing and is not a clinical or diagnostic assessment.