I’m curious about technology, quick to learn and eager to keep growing. I enjoy getting to grips with unfamiliar systems, asking questions and turning what I learn into something useful for other people.
How I work with colleagues
I bring a positive outlook, energy and a service-minded attitude. I enjoy helping colleagues, understanding what they need and finding a practical way forward. I want people to feel comfortable asking for help or sharing an idea—and I like bringing some good energy to the team while we get the work done.
I aim to be structured, reliable and proactive. I take ownership of my responsibilities, follow through and look for what needs attention before it becomes urgent. I like getting things done, with clear communication and enough documentation for somebody else to understand the work.
I feel at home working across teams, disciplines and countries. I enjoy the pace and different perspectives of a global environment, and I’m comfortable moving between technical conversations and the concerns of the people using a system.
The drive to keep growing
I’m ambitious about what I can learn and contribute. I want to take on harder problems, earn greater responsibility and work alongside people who challenge me. When something interests me, I put energy into understanding it and seeing it through.
That drive is a big part of why I build outside my day job. My projects give me room to try ideas, learn from mistakes and stretch beyond what I already know. I want that growth to make me a better engineer and a better colleague.
Where it started
I didn’t start by trying to become somebody who worked across infrastructure, security, automation and AI.
I started much closer to the user.
A person couldn’t access something.
A laptop wasn’t behaving.
An application needed to be deployed.
An account needed the correct permissions.
Success was normally clear:
solve the problem and move on.
Over time I became less satisfied with stopping there.
Why did the problem happen?
Who else could have it?
Which system actually owns the failure?
Why didn’t we detect it earlier?
Could the process be automated?
Could the control be safer without making the user’s job impossible?
What happens when the person who knows how this works is not available?
Those questions gradually pulled me deeper into the systems underneath the ticket.
At Corti my work now spans endpoint management, identity and access, security, Linux and GPU infrastructure, storage, networking, observability, vulnerability remediation, automation and the technical side of compliance.
A problem can start on somebody’s laptop and eventually lead into identity configuration, infrastructure permissions, Linux, storage, monitoring or a security control.
That is the kind of problem I enjoy.
Not because I expect myself to be the deepest specialist in every layer, but because I am comfortable following the system across those boundaries until the failure makes sense.
My independent work extends the same thinking into product development and AI.
AnySeller forces me to think about the relationship between engineering decisions and business operations.
Purple Hive forces me to operate and recover the infrastructure I design.
APEX and Purple Guard force me to decide how much authority an AI system should have and what evidence it should produce before that authority increases.
Those projects are separate from my work at Corti.
What connects them is the way I think.
From the fix to the system
The biggest change in my career has probably been this:
Earlier, I wanted to become the person who knew how to fix difficult things.
Now I want to build things that do not depend on one person knowing the magic command.
That changes how I approach a problem.
I still want the incident resolved.
But afterwards I want the reasoning documented, the repeated steps automated where appropriate, the important conditions observable and the recovery path understandable by somebody other than me.
The fix is useful.
The transferable system is more valuable.
Why Dinx Systems exists
Dinx Systems is the home for that work.
It is where I document systems I have built, operated and learned from.
Some are operating.
Some are still being built.
Some are experiments.
I would rather show that difference clearly than make everything look finished.
The goal isn’t to prove that I know every technology.
It is to show how I approach unfamiliar problems, how I make decisions, where I have been wrong, what I changed afterwards and what I am learning next.