Hi, I’m Ashley. 👋
I’m a tech enthusiast with a particular curiosity for how systems are built, behave and occasionally break.
Kernel Panic is my technical notebook. It’s where I document obscure issues, architectural decisions, and the kind of edge-case fixes that are too specific to remember but too useful to lose.
If something appears here, it’s because I hit it, found a solution, and decided future-me shouldn’t have to rediscover it.
About Me
I started my IT career in 2005 as an IT Technician in the education sector.
In 2014, I moved into the MSP world as a Support Engineer, working across a wide range of environments and infrastructure challenges. Over time, that evolved into leadership roles, and I currently serve as Head of Technical Delivery.
That journey has shaped how I approach technology:
- Pragmatic over theoretical
- Structured over improvised
- Stable over fashionable
Experience has a way of teaching you what actually matters.
Beyond Work
Outside of my day job, I volunteer as a Group Lead Volunteer for a local Scout Group.
Leadership in a voluntary organisation teaches a different kind of resilience – balancing responsibility, community, and limited resources.
What This Site Is
Most of the content here stem from real-world technical issues I’ve encountered and worked through.
- Some are mildly irritating.
- Some are quietly catastrophic.
- All of them taught me something.
Kernel Panic exists to capture those lessons – without the corporate polish and hopefully without the unnecessary drama.
What I’m Interested In
I tend to gravitate toward infrastructure, networking and the mechanics of how systems fit together.
I’m particularly interested in how things fail – and how to design them so that when they do, they fail predictably.
Security isn’t something I bolt on afterwards. It influences how I think about exposure, segmentation and risk from the outset.
I’m not especially interested in chasing trends. I prefer technology that is deliberate, understandable and stable.
The Lab
Alongside all of that, I run a homelab.
Not because I need to mirror production environments – but because I enjoy building and refining infrastructure on my own terms.
It’s a playground.
- Sometimes that curiosity overlaps with real-world scenarios.
- Sometimes it’s just because 10Gb was available and I wanted to use it.
Not everything needs a business case.
Why This Exists
I’m not a prolific writer – and I don’t intend to be.
Most of what appears here is written because I’ve hit something obscure enough that it’s worth documenting properly.
I don’t particularly enjoy writing for the sake of it. I do value not solving the same problem twice.
If sharing a fix or a lesson learned saves someone else time, then it’s worth putting it down.
Use of AI
Writing isn’t something I naturally enjoy, so I occasionally use AI tools to help shape and polish content for clarity. The technical experiences and lessons documented here are my own. AI simply assists with structure and readability.
Where images are included, they are either created by me or generated using AI tools to avoid copyright issues.
Final Thought
If something here saves you time, prevents a rebuild, or reassures you that you’re not the only one who’s hit a bizarre edge case – then it’s done its job.